PÁG 32 Criterios de evaluación

The best prevention against SUID/SGID attacks is to remove the SUID/SGID bit on as many files as possible. It is difficult to give a definitive list of files that should not be SUID, as there is a large variation among UNIX vendors. Consequently, any list that we could provide would be incomplete. Our best advice is to inventory every SUID/SGID file on your system and to be sure that it is absolutely necessary for that file to have root-level privileges. You should use the same methods attackers would use to determine if a file should be SUID. Find all the SUID/SGID files and start your research.

The following command will find all SUID files:

find / -type f -perm -04000 –ls

The following command will find all SGID files:

find / -type f -perm -02000 -ls

Consult themanpage, user documentation, and HOWTOs to determine if the author and others recommend removing the SUID bit on the program in question. You may be surprised at the end of your SUID/SGID evaluation to find how many files don’t require SUID/SGID privileges. As always, you should try your changes in a test environment be- fore just writing a script that removes the SUID/SGID bit from every file on your system. Keep in mind, there will be a small number of files on every system that must be SUID for the system to function normally.

Linux users can use Bastille (http://www.bastille-linux.org/) to harden their system against many of the aforementioned local attacks, especially to help remove the SUID from various files. Bastille is a fantastic utility that draws from every major reputable source on Linux security and incorporates their recommendations into an automated hardening tool. Bastille was originally designed to harden RedHat systems (which need a lot of hardening); however, version 1.10 and above make it much easier to adapt to other Linux distributions.

World-Writable Files Another common system misconfiguration is setting sensitive files to world writable, allowing any user to modify the file. Similar to SUID files, world writables are normally set as a matter of convenience. However, there are grave security

consequences in setting a critical system file as world writable. Attackers will not over- look the obvious, even if the system administrator has. Common files that may be set world writable include system initialization files, critical system configuration files, and user startup files. Let’s discuss how attackers find and exploit world-writable files.

find / -perm –2 –type f –print

Thefindcommand is used to locate world-writable files.

/etc/rc.d/rc3.d/S99local /var/tmp /var/tmp/.X11-unix /var/tmp/.X11-unix/X0 /var/tmp/.font-unix /var/lib/games/xgalscores /var/lib/news/innd/ctlinnda28392 /var/lib/news/innd/ctlinnda18685 /var/spool/fax/outgoing /var/spool/fax/outgoing/locks /home/public

Based on the results, we can see several problems. First, /etc/rc.d/rc3.d/ S99localis a world-writable startup script. This situation is extremely dangerous, as at- tackers can easily gain root access to this system. When the system is started,S99local is executed with root privileges. Thus, attackers could create a SUID shell the next time the system is restarted by performing the following:

[tsunami]$ echo "/bin/cp /bin/sh /tmp/.sh ; /bin/chmod 4755 /tmp/.sh" \

/etc/rc.d/rc3.d/S99local

The next time the system is rebooted, a SUID shell will be created in/tmp. In addi- tion, the/home/publicdirectory is world writable. Thus, attackers can overwrite any file in the directory via themvcommand. This is possible because the directory permis- sions supersede the file permissions. Typically, attackers would modify thepublicus- ers shell startup files (for example, .loginor .bashrc) to create a SUID user file. After publiclogs in to the system, a SUID public shell will be waiting for the attackers.

U

World-Writable Files Countermeasure

It is good practice tofindall world-writable files and directories on every system you are responsible for. Change any file or directory that does not have a valid reason for be- ing world writable. It can be hard to decide what should and shouldn’t be world writable, so the best advice we can give is common sense. If the file is a system initialization file, critical system configuration file, or user startup file, it should not be world writable. Keep in mind that it is necessary for some devices in/devto be world writable. Evaluate each change carefully and make sure you test your changes thoroughly.

Extended file attributes are beyond the scope of this text, but worth mentioning. Many systems can be made more secure by enabling read-only, append, and immutable flags on certain key files. Linux (viachattr) and many of the BSD variants provide addi- tional flags that are seldom used but should be. Combine these extended file attributes with kernel security levels (where supported), and your file security will be greatly en- hanced.

]

Shell Attacks

The UNIX shell is extremely powerful and affords its users many conveniences. One of the major features of the UNIX shell environment is its ability to program commands as well as to set specific options that govern the way the shell operates. Of course, with this power come risk and many avenues of attack. One common avenue of attack is abus- ing the Internal Field Separator (IFS) variable.