Tech
Protect against root exploits in Unix systems
One of the most dangerous situations is when hackers take hold of the superuser (root or administrator) access. Here's how you can identify and recover from rootkits in Unix.
When attackers take advantage of an exploit, one of their first goals is to gain superuser (root or administrator) access to the compromised system. If the compromised process is already running with superuser privileges, the actual exploit performs this step for them.
This is the case with many of the Windows Internet application exploits because they run as administrator. For many of the common Windows system exploits, the privileges of the compromised process allow attackers to completely take control of a system--and perhaps even install a remote-executable command interpreter or a "backdoor" program to allow further access to the system.
Many intruders then close the vulnerability that allowed them access to the system to prevent anyone else from exploiting it, remove evidence of the exploit, and install the software of their choice. The attacker now "owns" the system.
Identify rootkits
On UNIX systems, many applications run with superuser privileges, which is the root user on UNIX. Applications that run as root on UNIX systems are ripe targets for intruders. In this way, UNIX and Windows share the same concerns regarding applications that need superuser access.
Internet applications that run as root on a UNIX system typically need to allow access by multiple user accounts or need to process information as multiple users. These include applications such as OpenSSH, most e-mail server software (e.g., Sendmail), and FTP daemons. Many applications, such as Apache Web server, switch user privileges to a nonroot user after starting and binding to a network service port to try to prevent root exploits, but some applications can't do this.
But switching user rights to a nonroot user on UNIX doesn't mean that your application is secure. Local root exploits exist as well, and if intruders can run arbitrary commands remotely, they'll surely attempt to break into a system and obtain root access. Once intruders gain root access, their next step is to install a rootkit to maintain that access and wipe away traces of the exploit.
A rootkit is a collection of replacement programs for essential UNIX system commands that facilitates cleaning up after an exploit and maintaining access to a compromised system. Unless you can validate the authenticity of these programs, you may not even know someone has compromised your machine.
Programs such as Tripwire maintain signatures of system files and changes, and they can alert an operator that there's a problem. Tripwire is available in both commercial and open source versions, and many consider it the de facto standard for protecting UNIX operating systems from rootkits.
There's also an excellent open source tool called chkrootkit that can quickly check for various popular UNIX rootkits. If you aren't using Tripwire and suspect that someone has compromised your UNIX system, I suggest downloading and using chkrootkit immediately.
If your machine is clean, then it's either well maintained or you're lucky--or both. It's a good idea to go ahead and install Tripwire anyway.
Recover from rootkits
It is not enough kust to know about rootkits on your UNIX system, you need to take steps to remove them.
You can use commercial or open source programs, such as Tripwire or chkrootkit, to detect rootkits on your system. However, finding out someone has compromised your UNIX system is one thing--cleaning up the resulting mess is entirely another.
Getting rid of rootkits can be a complicated matter. UNIX doesn't have a consistent package standard, which means that reinstalling the entire operating system is the usual method of recovery.
This isn't good news for many people, especially when the compromised system contains irreplaceable data. Backups help, and you can clean many systems without taking them offline.
Linux systems that use the Red Hat Package Manager (RPM) can quickly verify the integrity of system files by running the rpm -Va command as the root user. The command's output is a listing of files and directories that have changed in some way from their original versions, but this doesn't mean that there's an installed rootkit. Be advised that changes to command files such as netstat, ifconfig, ps, and chsh are typical with rootkits, regardless of the UNIX operating system in use.
If you suspect or know that someone has installed a rootkit, the first thing to do is unplug the network connection and try to shut down and restart the compromised machine in single-user mode. If you have a "rescue" boot disk or CD-ROM, this is the time to use it.
Once you've brought up the machine in single-user mode, you can begin the recovery process. If you don't have a "rescue" disk available for your Linux system, try searching for one on Google.
Intruders typically change the attributes of rootkit files on Linux systems to prevent someone from replacing them. Running the lsattr command on suspect files or directories will show differences when compared to other executable program files.
Files marked with the "immutable" flag ("i") are always suspect. This flag implies that someone has changed the rootkit files using the chattr command to prevent you from deleting or replacing the files.
The key to recovery is making sure that you don't change the wrong files. Rootkits frequently replace files in /bin, /sbin, /usr/bin, and /usr/sbin, which are some of the main file system locations that UNIX uses for its commands. Rootkits also place directories and files outside of these areas, but unless you're absolutely sure that these files belong to a rootkit and not to a legitimate application, you should leave them alone.
If you find a suspected rootkit file, you need to replace it with a legitimate copy. If your Linux distribution uses RPM, use rpm -q -f {file} to find the packages that provide the compromised files. Using RPM, the best way to replace the compromised files is by reinstalling the entire package, so you'll need your installation CD-ROM or the package files from some source.
But before you can replace packages, you have to "unlock" the compromised files that were marked immutable. On Linux, the chattr -i command unlocks files so you can delete or replace them. (Consult the manual pages for lsattr and chattr for more information on these commands.) After unlocking the compromised files, you can use the rpm -Uvh {package} command to reinstall the package, which replaces the compromised files.
Replacing the compromised files doesn't mean that you're out of the woods yet, but if you need to get a machine back online in a hurry, this is one way to do it. Sometimes it's more important to get a machine back online quickly than it is to figure out how the intruder compromised the machine in the first place. But this investigative work definitely should be your next step, or someone will likely compromise the machine again.
This article first appeared in a Techrepublic e-newsletter.
Jonathan Yarden is the senior UNIX system administrator, network security manager, and senior software architect for a regional ISP.
This is the case with many of the Windows Internet application exploits because they run as administrator. For many of the common Windows system exploits, the privileges of the compromised process allow attackers to completely take control of a system--and perhaps even install a remote-executable command interpreter or a "backdoor" program to allow further access to the system.
Many intruders then close the vulnerability that allowed them access to the system to prevent anyone else from exploiting it, remove evidence of the exploit, and install the software of their choice. The attacker now "owns" the system.
Identify rootkits
On UNIX systems, many applications run with superuser privileges, which is the root user on UNIX. Applications that run as root on UNIX systems are ripe targets for intruders. In this way, UNIX and Windows share the same concerns regarding applications that need superuser access.
Internet applications that run as root on a UNIX system typically need to allow access by multiple user accounts or need to process information as multiple users. These include applications such as OpenSSH, most e-mail server software (e.g., Sendmail), and FTP daemons. Many applications, such as Apache Web server, switch user privileges to a nonroot user after starting and binding to a network service port to try to prevent root exploits, but some applications can't do this.
But switching user rights to a nonroot user on UNIX doesn't mean that your application is secure. Local root exploits exist as well, and if intruders can run arbitrary commands remotely, they'll surely attempt to break into a system and obtain root access. Once intruders gain root access, their next step is to install a rootkit to maintain that access and wipe away traces of the exploit.
A rootkit is a collection of replacement programs for essential UNIX system commands that facilitates cleaning up after an exploit and maintaining access to a compromised system. Unless you can validate the authenticity of these programs, you may not even know someone has compromised your machine.
Programs such as Tripwire maintain signatures of system files and changes, and they can alert an operator that there's a problem. Tripwire is available in both commercial and open source versions, and many consider it the de facto standard for protecting UNIX operating systems from rootkits.
There's also an excellent open source tool called chkrootkit that can quickly check for various popular UNIX rootkits. If you aren't using Tripwire and suspect that someone has compromised your UNIX system, I suggest downloading and using chkrootkit immediately.
If your machine is clean, then it's either well maintained or you're lucky--or both. It's a good idea to go ahead and install Tripwire anyway.
Recover from rootkits
It is not enough kust to know about rootkits on your UNIX system, you need to take steps to remove them.
You can use commercial or open source programs, such as Tripwire or chkrootkit, to detect rootkits on your system. However, finding out someone has compromised your UNIX system is one thing--cleaning up the resulting mess is entirely another.
Getting rid of rootkits can be a complicated matter. UNIX doesn't have a consistent package standard, which means that reinstalling the entire operating system is the usual method of recovery.
This isn't good news for many people, especially when the compromised system contains irreplaceable data. Backups help, and you can clean many systems without taking them offline.
Linux systems that use the Red Hat Package Manager (RPM) can quickly verify the integrity of system files by running the rpm -Va command as the root user. The command's output is a listing of files and directories that have changed in some way from their original versions, but this doesn't mean that there's an installed rootkit. Be advised that changes to command files such as netstat, ifconfig, ps, and chsh are typical with rootkits, regardless of the UNIX operating system in use.
If you suspect or know that someone has installed a rootkit, the first thing to do is unplug the network connection and try to shut down and restart the compromised machine in single-user mode. If you have a "rescue" boot disk or CD-ROM, this is the time to use it.
Once you've brought up the machine in single-user mode, you can begin the recovery process. If you don't have a "rescue" disk available for your Linux system, try searching for one on Google.
Intruders typically change the attributes of rootkit files on Linux systems to prevent someone from replacing them. Running the lsattr command on suspect files or directories will show differences when compared to other executable program files.
Files marked with the "immutable" flag ("i") are always suspect. This flag implies that someone has changed the rootkit files using the chattr command to prevent you from deleting or replacing the files.
The key to recovery is making sure that you don't change the wrong files. Rootkits frequently replace files in /bin, /sbin, /usr/bin, and /usr/sbin, which are some of the main file system locations that UNIX uses for its commands. Rootkits also place directories and files outside of these areas, but unless you're absolutely sure that these files belong to a rootkit and not to a legitimate application, you should leave them alone.
If you find a suspected rootkit file, you need to replace it with a legitimate copy. If your Linux distribution uses RPM, use rpm -q -f {file} to find the packages that provide the compromised files. Using RPM, the best way to replace the compromised files is by reinstalling the entire package, so you'll need your installation CD-ROM or the package files from some source.
But before you can replace packages, you have to "unlock" the compromised files that were marked immutable. On Linux, the chattr -i command unlocks files so you can delete or replace them. (Consult the manual pages for lsattr and chattr for more information on these commands.) After unlocking the compromised files, you can use the rpm -Uvh {package} command to reinstall the package, which replaces the compromised files.
Replacing the compromised files doesn't mean that you're out of the woods yet, but if you need to get a machine back online in a hurry, this is one way to do it. Sometimes it's more important to get a machine back online quickly than it is to figure out how the intruder compromised the machine in the first place. But this investigative work definitely should be your next step, or someone will likely compromise the machine again.
This article first appeared in a Techrepublic e-newsletter.
Jonathan Yarden is the senior UNIX system administrator, network security manager, and senior software architect for a regional ISP.