29.0 Unix Local Attacks
This section deals with attacking Unix from a local account or from the console itself.
29.1 Why attack locally?
When you are trying to gain root on a file server, one method to start with is to gain at least limited access on the system. There are large number of exploits to "bust root" but many require you have an account on the box. Here is an example attack scenario:
- Gain access to server www.example.com via guest account (note to idiots: this domain is reserved).
- Note that it's running an older version of Linux.
- Prowl around on Bugtraq or some other place with exploit code, and find an exploit for one of the outdated or unpatched programs or subsystems.
- Compile and run it to become root.
- Brag to all your friends and on IRC so you get caught and go to jail (this step is optional).
29.2 How do most exploits work?
There are several different attack techniques you can use from a local account and the handy exploit you are running. Here are a few common ones with extremely simple explanations:
- If excessive permission exist on certain directories and files,
these can lead to gaining higher levels of access. For example, if /dev/kmem is writable, it is possible to rewrite your UID to match root's. Another example would be if a .rhosts file has read/write permissions allowing anyone to write them. Yet another example would be a script launched at startup, cron, or respawned. If this script is editable, you could add commands to run with the same privileges as who started them (for startup rc files, this would be as root).
- Poor SUID
- Sometimes you will find scripts (shell or otherwise) that perform certain tasks and run as root. If the scripts are writable by your id, you can edit it and run it. For example, we once found a shutdown script world writable. By adding a few lines at the beginning of the script it was possible to have the script create a root shell in /tmp.
- Buffer Overflow
- Buffer overflows are typically used to spawn root shells from a process
running as root. A buffer overflow could occur when a program has a buffer for user-defined data and the user-defined data's length is not checked before the program acts upon it. See the next question for more details.
- Race Conditions
- A Race Condition is when a program creates a short opportunity for evil
by opening a small window of vulnerability. For example, a program that alters a sensitive file might use a temporary backup copy of the file during its alteration. If the permissions on that temporary file allow it to be edited, it might be possible to alter it before the program finishes its editing process.
- Poor Temp Files
- Many programs create temporary files while they run. If a program runs
as root and is not careful about where it puts its temp files and what permissions these temp files have, it might be possible to use links to create root-owned files.
29.3 So how does a buffer overflow work?
A buffer overflow works as follows:
- Program eleetd has unchecked user input and is owned by root.
- Hacker creates program that sends user input greater than what eleetd's buffer for the input will hold.
- Hacker has made sure that this data when placed upon the stack will alter the next instruction the CPU will execute.
- Hacker runs evil program and the hacker's command, /bin/sh, runs as root, dropping the hacker to a shell running as root.
For example, if the buffer holds 108 bytes, the hacker creates a program that sends more than 108 bytes to that buffer. By carefully crafting the extra bytes starting at byte 109, the hacker can make the program execute additional commands.
For more information on buffer overflows, check out Mudge's tutorial on writing them, or read this overview in a paper called Compromised - Buffer Overflows, from Intel to SPARC Version 8. Another fine article appeared in Phrack 49, File 14, called Smashing The Stack For Fun And Profit by Aleph One.
Top | Next: Unix Remote Attacks | Previous: Unix Passwords | Table of Contents