Potential Vulnerabilities in Shared Systems

by st4r_runner

Having a shell account on a shared system is convenient, fun, and dangerous.

A lot of web-hosting services provide shell access and some ISPs offer shell accounts on their Linux/UNIX boxes.  If you're lucky enough to have one, you should be aware of the potential for information leakage and protect yourself on these systems.

Let's demonstrate how to harvest some info.  First, prepare your environment to avoid leaving a telltale trail:

$ rm ~/.bash_history

then:

$ ln -s /dev/null ~/.bash_history

If it's not a Bash shell, then do the same for the .sh_history or whatever the case may be.

Now let's see what we have for user directories:

$ ls -al /home

You'll probably get permission denied.  No problem:

$ cat /etc/password

Should show you all the user directories anyway.  What's in their directories?  Hopefully:

$ ls -al /home/username

won't work (but you never know).  So where can you go from there?  See if perhaps their .bash files are readable:

$ ls -l /home/username/.bash_history $ ls -l /home/username/.bash_profile $ ls -l /home/username/.bashrc

Are any of those readable (rw-r--r--)?

Take a look at them.  They may show some interesting information.

Now here's where it can get interesting.  Most shell servers will have a web server available for sharing out a personal web page.  This directory will likely be ~/public_html (you should have the same directory).

But if you want to be sure then:

$ grep UserDir httpd.conf

httpd.conf can be located in different places depending on the installation.  Some common locations are /etc/httpd, /etc/apache, /usr/local/apache/conf, or /var/www/conf, or do:

$ ps ax | grep httpd

and it might show you the full command line (/usr/sbin/httpd -f /etc/httpd/httpd.conf).

Once you know the UserDir, guess what?  That directory is world readable.  Big deal, right?

Well take the time to poke a little further.  Users are notorious for storing sensitive information in those directories.  They think that just because they don't provide a link for that file or directory on their little web page means that no can get to it.  Users will put things like bank-info.xls or pic-of-wife-no-one-should-see.jpg or myfavband.mp3.

What else could we do?  Let's see.  Ah, the user is running PHP-Nuke or some other PHP/MySQL-based portal and they have a nice config.php file:

$ ls -l /home/username/www/*.php

You'd be surprised at how many users make their database password the same as their login password to that system.

$ vi /home/username/www/config.php

Hmm...  dbuname=username and dbpass=my-secretpw.  O.K.  So now I own their database.  But I wonder if they would be dumb enough to have that same password for this system:

$ ssh -l username localhost

Just do it from localhost, not your home system (if the user or sysadmin runs the last command it will reveal your IP address).  If the login is unsuccessful, don't worry.  There may be more to look at still.

How about writable files and directories?

$ find /home/username/www -perm 0777 -print $ find /home/username/www -perm 0666 -print

Play around with permission modes.  6 or 7 in the last position is what you're looking for.

If a user has a writable directory then you can put your own files in there.  If a user has a writable file, like a PHP file, then you can put your own spyware into the code to let you know when users access the page or if it has a login form you can write code in there to write the username and password to a file for you to collect later on.  Whatever.

Now be careful of what you do.  You are not allowed to violate someone's privacy or destroy their content.

Some Linux administrators have gotten smart and used grsecurity's patches to log all exec() from users so they can be alerted if some user is running find / -perm 0777.  You will get caught.  So make sure that you stay under the radar.

To find out if the system is a grsecurity kernel:

$ uname -a

Well, have fun poking around but don't do anything stupid.