| Previous | Table of Contents | Next |
NIS Passwd Files
Many NIS servers do not have access control. Any client that is able to provide a domain name can bind to the server. Once bound, the client system can request any of the NIS maps, including the passwd map, hosts map, and aliases map. The only protection for these maps is the secrecy of the domain name. Because domain names are usually descriptive and simple, they can frequently be guessed. However, if the remote system runs a bootparam service from the portmap program, an rpc call to this service returns the domain name.
SATAN interrogates the bootparam services, gets the domain name, and gets the passwd map. After an intruder has this map, a Crack program can attempt to guess the passwords.
NIS servers should not be accessible to users on the other side of the firewall—the average Internet user. They should always be used behind (and not on) firewalls that filter out traffic on port 111 (portmap).
Portmap Forwarding
A feature of some portmapper daemons is the capability to forward an rpc call to the mountd program. Because mountd authenticates the client rpc call based on the source IP address, a request originating from the portmap program would appear to originate from the local system. A remote user on an unauthorized client host could use this forwarding feature to bypass IP access restrictions in the exports file. As long as the local system was permitted to gain access to itself, the mountd would reply with the file handle for the NFS mount. Once the hacker obtained the file handle, the subsequent NFS rpc calls would be approved because no further IP authentication is done by the nfsd or nfs routines in the kernel.
A new portmap program (and rpcbind) prevents such forwarding, and this fix has been adopted by most vendors. Get the new version of portmap to ensure that your system is not vulnerable to this attack.
Note: More details on this vulnerability are available from CERT bulletin CA-94:15, NFS Vulnerabilities. A fixed version of portmap and rpcbind is referenced in this document.
SATAN attempts to get the portmap program to forward a request to the mountd to mount the exported file systems. This and all the other NFS checks done by SATAN are generated in the nfs-chk/nfs-chk.c program. The code is well commented and demonstrates how this attack could be exploited by a hacker.
tftp File Access
Many tftpd implementations do no authentication on incoming requests. Because inetd (with inetd.sec, tcp-wrapper, or xinetd) can do authentication, tftpd should be started only from inetd and should exit after servicing one request. tftpd should be restricted to dealing with a limited directory subtree containing only necessary files.
A hacker with access to a tftpd that permits access to / can enter a new /etc/passwd, because tftpd has no authentication and is frequently run as root out of inetd. A hacker with access only to the tftp directory can still enter a corrupted version of configuration or boot files. Note that tftpd does not usually provide a listing facility to show what files exist in the directory. Although this improves security by not offering hackers a list of files to attack, it is not enough. Based on knowledge about the OS, the names of boot files and configuration files are typically quite similar. The hacker can sequence through guesses based on the OS and usually find a correct filename.
Remote Shell Access
rshd (remshd) and rlogind are services that permit access based on trust. Trust is determined by a match between the hostname and login name sent by the remote system in the initial packet, and the presence of that hostname and login name, or wild cards, in the local .rhosts or hosts.equiv file.
One analogy to this situation, which might illustrate the weaknesses, is if you are a bank manager and you tell your tellers to trust anyone named Bob calling from Cleveland.
The presence of wild cards make this situation even more dangerous. The typical entry in .rhosts or hosts.equiv is a hostname followed by a username, such as systemA userB. The wildcard entry systemA + permits any user from systemA to gain access. The wild card entry + + permits any user from any machine to gain entry.
The analogy to this situation is that you tell your tellers to trust anyone who claims to be calling from Cleveland, or anyone who calls at all.
The presence of + + in the /.rhosts file is almost always an indicator that a hacker has gained access to your system. This addition to /.rhosts is the primary goal of most attack scripts.
The first improvement to rshd (remshd) and rlogind to deal with improving trust-based security was the reverse name lookup using the DNS resolver. The IP address of the source of the TCP connection is used to do a gethostbyaddr() call that returns the fully qualified domain name of the host that owns that IP address. If the hostname matches the hostname sent by the initial protocol, access is permitted.
This is comparable to requiring each teller to call the Cleveland phone company and ask them to trace the phone number of the incoming phone call, then looking up the owner of that phone number. If the owner’s name matches the name claimed by the caller, access is approved.
This improvement does not solve the problem completely. If the resolver lookup for the hostname contacts a caching name server, the name server could have cached a faked PTR entry that points to the intruder’s name server. If the intruder has control over a legal name server that is delegated authority over a network by the Internic, the intruder can easily modify the name server database to facilitate this attack, without having to corrupt the cache of other name servers (Bellovin, 1993; Schuba & Spafford, 1993).
Note: The ftpd server bounce problem mentioned in an earlier section cannot be used to exploit the TCP port number sent in the opening of the rshd (remshd) protocol. It is true that the start of the rshd protocol permits the client to specify a TCP port number for remote errors (stderr) to be sent to; however, the TCP port is only on the client system. Any hacker who wanted to send a potentially untraceable packet, by specifying a reserved port number such as smtp or FTP, would first require root access to the system to be able to send the initial rsh (remsh) protocol, because they must originate from a reserved port and such ports can be obtained only by a root user. The hacker would need to be root on the client system to use this attack, and if the hacker was root, such an attack would not be necessary.
| Previous | Table of Contents | Next |