Things You Shouldn't Do

I love "hacking".(Such as I do.) But, my first love was system administration. There is a lot of satisfaction, to a neat freak like me, to create and administer a finely tuned FreeBSD server. It honestly makes me giddy to think of all the system configs properly formated and commented, etc. Having a tidy system that follows correct guidelines is not only a beautiful thing, but it is also usually a secure thing. A lot of insecurities that I see in my job are caused by having an untidy system, coding untidy spaghetti code, or running an untidy framework or operating system.(I'm looking at YOU ColdFusion and Windows. ;])

I recently performed a test on a system that was a bad example of being tidy. I would like to talk about a few things that could have prevented me getting shell on this particular box.

= The Story =

There was a target hosting samba shares. I had credentials to a few of these file shares and decided to access one them. As I listed the contents of the directory, something caught my eye. I looked again. Sure enough, I had seen a .viminfo file fly by. I looked around a little more and saw a .bash_history file and a .ssh folder. Oh my! "This couldn't possible work" I said to myself as I generated an SSH key. I edited the .ssh/authorized_keys file and added my key, and was able to SSH to the box with a user name that matched the samba user name.

= What Went Wrong =

Let us evaluate some of the things that were "untidy" about this box and why they caused me to get shell access.

= Services Were Pointing to a Home Directory =

This was the biggest mistake made. Services should never be pointed to a user's home directory. This is terrible because if the service is FTP, Samba, etc. then a user of that service would be able to add/edit configuration files belonging to that user. This means they could add SSH keys for SSH access, steal SSH keys that have been generated on the system, view your bash history to see what you are doing on the system, check your .viminfo to see what changes you made to config files as that user, and edit any other config they desire.

Pointing other services like Apache or an IRC server to a user's home directory can also be harmful by providing read access to users of those services. Or, allow attackers to potentially manipulate that service to access config files belonging to that user.

= User Settings =

Not running all services as root is a good idea.(That is why many systems will create an apache or postgres user.) Also, user management can be good to add extra security to file access on a system. But, not every user needs to have a password, and not every user needs to be able to log in. Who in their right mind would give the "daemon" or "sshd" user a password? Or give them bash as a login shell? Any user of this type should not be able to login and should have a "nologin" shell.(Check your OS instructions for doing this) Configure your users carefully.

= SSH Policy =

Not all users who can login to the system should have SSH access. Root should not have SSH access either.(This makes bruteforcing access easier.) Consider also adding an AllowUsers line in your sshd_config.

= SSH key policy =

Does this user really need an SSH key on a remote system? Or should the remote system have a public key on this one? You be the judge. But unless you have an automated process using an SSH key to periodically transfer files to this machine, make sure you have a password on your SSH keys!(Also, remember that with the aid of your known_hosts file, I know what machines this key may give me access to.)

= User Directories Should Be In The Correct Location =

This is probably how a service was pointed to a Home directory in the first place. I found out, after gaining shell access, that a number of users had their home directories in /export/$USER instead of /export/home/$USER.(This is a solaris system.) This is NOT a tidy system! This leads to confusion and mistakes! Again, configure your users carefully.

= System Updates =

Allowing someone to obtain shell access on a secure system is bad. Shell access to an outdated system with privilege escalation vulnerabilities is worse.(That's what happened in this case.) Updates should be applied in a timely manner.

= Do Not Reuse Passwords =

Turns out, all of this fileshare + SSH key nonsense was more work than I needed to do. This system had not only created a user with the same name as the file share I was accessing, but they had give the user the same password as well. Shell access was as easy as SSHing to the box as a legitimate user. palm(face)

= Logging =

With the major problems on this system, I encouraged the administrator to check their logs to see if they could identify if any suspicious activity had already occurred. It turns out that almost all logging was disabled, was not being backed up, and was not being examined.

Hopefully this gives each of us Sys-Admins and System Architects some food for thought.