Telnetd Backdoor
When a user telnets to the machine, inetd service listens on the port and receive the connection and then passes it to in.telnetd, that then runs login. Some intruders knew the administrator was checking the login program for tampering, so they modified in.telnetd. Within in.telnetd, it does several checks from the user for things like what kind of terminal the user was using. Typically, the terminal setting might be Xterm or VT100. An intruder could backdoor it so that when the terminal was set to "letmein", it would spawn a shell without requiring any authentication. Intruders have backdoored some services so that any connection from a specific source port can spawn a shell.
Services Backdoor
Almost every network service has at one time been backdoored by an intruder. Backdoored versions of finger, rsh, rexec, rlogin, ftp, even inetd, etc., have been floating around forever. There are programs that are nothing more than a shell connected to a TCP port with maybe a backdoor
password to gain access. These programs sometimes replace a service like uucp that never gets used or they get added to the inetd.conf file as a new service. Administrators should be very wary of what services are running and analyze the original services by MD5 checksums.
Cronjob backdoor
Cronjob on Unix schedules when certain programs should be run. An intruder could add a backdoor shell program to run between 1 AM and 2 AM. So for 1 hour every night, the intruder could gain access. Intruders have also looked at legitimate programs that typically run in cronjob and built
backdoors into those programs as well.
Library backdoors
Almost every UNIX system uses shared libraries. The shared libraries are intended to reuse many of the same routines thus cutting down on the size of programs. Some intruders have backdoored some of the routines like crypt.c and _crypt.c. Programs like login.c would use the crypt() routine
and if a backdoor password was used it would spawn a shell. Therefore, even if the administrator was checking the MD5 of the login program, it was still spawning a backdoor routine and many administrators were not checking the libraries as a possible source of backdoors.
One problem for many intruders was that some administrators started MD5 checksums of almost everything. One method intruders used to get around that is to backdoor the open() and file access routines. The backdoor routines were configured to read the original files, but execute the trojan
backdoors. Therefore, when the MD5 checksum program was reading these files, the checksums always looked good. But when the system ran the program, it executed the trojan version. Even the trojan library itself, could be hidden from the MD5 checksums. One way to an administrator could
get around this backdoor was to statically link the MD5 checksum checker and run on the system. The statically linked program does not use the trojan shared libraries.
