Made of Everything You're Not

If you were a sysadmin a few years ago, and you had php on your servers, you’re probably already familiar with c99. In case you haven’t had the personal pleasure, c99, or specifically c99.php (hint: check the source), is the name of a script used by hackers to gain access to a web server running php using an exploit technique called Remote File Inclusion.

A Little History

See, back in the day some php developers were pretty stupid. (Admit it; you were stupid once too.) What other explanation could there be for writing code that allowed the injection of arbitrary routines into a program. Trivially easy too.

To be fair, PHP was to blame a little for this as well. Given PHP’s high adoption, and design, by, and for, newbie programmers allowing such a technique by default was just ill conceived, and maybe even a little negligent. I understand the desire, and sometime need, for a technique that could be dangerous but to enable the feature by default…. damn man…

So, the risk was known, yet code was still being written (like the below example) that allowed remote file inclusion to be possible. Mostly because of the aforementioned default setting.

<?php
$color = 'blue';
if (isset( $_GET ) )
{
	$color = $_GET;
}
require( $color . '.php' );
?>

BTW, if you currently write code that does anything like the above, frankly, you’re an idiot. You aren’t nearly as smart and clever as you think you are. I promise you this will bite you. Bad too.

About C99.php

So, using a technique like the above opens you up to learning first hand about c99.php. Finding information about the program itself is a little tricky but there are a couple examples that highlight just how devastating it can be.

When malicious intruders compromise a web server, there’s an excellent chance a famous Russian PHP script, r57shell, will follow. The r57shell PHP script gives the intruder a number of capabilities, including, but not limited to: downloading files, uploading files, creating backdoors, setting up a spam relay, forging email, bouncing a connection to decrease the risk of being caught, and even taking control of SQL databases. All these functions become readily available through an easy to use web interface, but now you can fight back.

Using the above explanation, which I agree with, c99.php acts as an interface to control your server. Once it’s on your server an attacker has easy access to view all the files and their contents, make changes to the system, upload new files, manipulate the database(s) and more.

Quite the nasty little script but pretty elegant in how it’s implemented. c99 is a completely standalone script; even the images are embedded inside using base64!

Until a month ago I would have thought the risk of encountering c99.php in the wild would have been small these days. Then, SMACK!!, a client had a site get hacked (quick CYA; that I didn’t’ work on ) using c99. So be warned. It’s out there and if you’re not smart, or if you’re a lazy, lazy, coder, c99 will get you.

Among the few hassles to being a citizen of the Internets, along with multiple login credentials, comment trolls and pedophiles (obviously), is the hassle of multiple profile pics. Yes, it’s an extremely small problem but it is a problem solved by Gravatar.

Gravatar, which stands for Globally Recognized Avatar (seriously), is a service provided by Automattic (yes, the same Automattic that provides WordPress) that allows users to upload a single image which developers can then use on their websites. The outcome is that users have a single icon (or avatar) representing them, that they don’t have to repeatedly upload. Another, less publicized benefit, is that us developers don’t have to write all the photo uploading and resizing functionality. Again.

The Basics

From an implementation standpoint Gravatars couldn’t be simpler. At the base level it’s just a call to a URL that includes an md5() hash of a users email. For example my gravatar URL is the below:

http://www.gravatar.com/avatar/8a55f4e419d6d5314e420ba26bf7455e?s=75&d=wavatar&r=X

Looking at the URL (which hopefully, you’re comfortable looking at) it’s broken up like so:

Base URL: http://www.gravatar.com/avatar/

My Identifier (eric@ericlamb.net in md5()): 8a55f4e419d6d5314e420ba26bf7455e

Query String Parameters: s=75&d=wavatar&r=X

As far as the query string goes, none of the below are required but using them allows to customize the output. You have the following options:

Image Size: s (between 1 and 512)

Default: d (wavatar, identicon, monsterids or custom URL)

Rating: r (think movie ratings with G – X)

Considering all of the above, and how simple it is, I’m kind of amazed that there’s still an issue with wide adoption (though this could be due to Gravatar scaling the service for the obscene amount of traffic this would create) .

The Codes

Obviously, writing a little snippet to create the Gravatar URLs in PHP would be trivial to most programmers:

<?php
$url = 'http://www.gravatar.com/avatar/';
$email = 'eric@ericlamb.net';
$default = 'monsterid';
$size = 75;
 
$grav_url = $url.'?gravatar_id='.md5( strtolower($email) ).
'&default='.urlencode($default).'&size='.$size;
?>
<img src="<?php echo $grav_url;?>" />

Simple but the code above could be a lot more useful. As expected though, a few php classes have been written that’ll handle all the particulars for you. One, available on phpclasses.org, I looked at, and even used within a project, but it didn’t have native support for “defaults” so I decided against using it as an example here (still a cool script if the next one doesn’t float your boat).

The other script is available through TalkPHP, so it’s not really clear who the actual author is (sorry for not giving credit whoever you are). The code is clean, clear and dead easy to implement though.

<?php
include_once('./TalkPHP_Gravatar.php');
$pAvatar = new TalkPHP_Gravatar();
$pAvatar->setEmail('adam@talkphp.com')->setSize(80)->setRatingAsPG()->setDefaultImageAsIdentIcon();
?>
<img src="<?php echo $pAvatar->getAvatar(); ?>" />

Very, very simple. I have to say I’m a fan of Gravatar. I wish more sites implemented Gravatars, instead of having me constantly uploading a different image, but now you can do your part. Get cracking.

With the release of Google Buzz last week a lot of people have been screaming bloody murder over some privacy concerns they have and Google’s perceived lack of forethought on the matter.

First, Google Buzz appears to be a FriendFeed clone that Google just launched about a week (or 2) ago. Initially, it was enabled inside of all gmail accounts by default without any authorization to the contrary. I haven’t had the opportunity to try it though. Not because I don’t use gmail (I do; sorta) but because I use Google Apps gmail which wasn’t a part of the rollout.

From what I can glean; Google Buzz works by parsing your contact list and then making connections between everyone in it and displaying their social network activity info publicly for all to see (seriously, just like FriendFeed). Make sense? No? Here’s the Crunchgear explanation of Google Buzz:

Google Buzz is a social network and sharing product built by Google. Based within Google Profiles, Buzz offers a stream of status updates, pictures, links, and videos from your friends. You can “like” these items and you can comment on them. Updates from Flickr, Picasa, Google Reader, or Twitter can also be automatically imported into a Buzz stream. Buzz will recommend items you might like based on your friends’ activity.

So, apparently, one of the “features” of Google Buzz is that when it was initially released it displayed your contact list publicly which raised all sorts of hell from people who can’t afford for this to happen (think lawyers, journalists, etc).

This smacks of a high level of naivete on most of the users. Under what delusion are people living in to think that they have any expectation of privacy from a publicly traded company. Yes, I know they claim to care about your privacy, and I’m sure on a personal level the people working for Google do, in fact, care about your privacy. But the organization itself? Not a fucking chance.

Let’s get serious here; as stated above, Google is a publicly traded company which means their priorities start and end with cash ($$$). Frankly, it’s naive to think otherwise. Ask any corporate officer and they’ll tell you they have a responsibility to their shareholders. This is a notorious lose for consumers but it’s the reality nonetheless. Cry all you want but Google fucking their users in this way did ensure they launched a new social network with millions of users. From a fiscal standpoint, this was a HUGE win even with all the bitching and moaning. Even taking into account any users who would leave Google (along with any ill will this may have created) this was still a winning strategy for launch.

If privacy is an issue then, it seems to me, that you really should have taken greater measures to protect yourself. Relying on Google to protect something like this screams of escapism and finger pointing. Guess what? It’s your fault. Deal with that instead of crying that a publicly traded company that provides a service you use for free does something in a way that you don’t like.

Do I think that Google was right in any way for doing what they did? Not for a second. That said, people need to take responsibility for their own needs instead of blindly trusting a for profit company to do it for them. Yes, even when that company claims to “do no evil”.

I was working on a project recently that was using WordPress as the base platform and had a need for a scheduled task function. Ordinarily, this would be the type of functionality that I would just setup a cron job for; but since Wordpress has a pseudo cron system in place I decided to investigate that as an option. Long story short; fuck that man.

As mentioned, Wordpress has a pseudo cron mechanism available to Wordpress developers for scheduling tasks called WP Cron. WP Cron works using series of functions available for plugin developers to create their own cron style tasks. In theory Wordpress makes this easy(ish) using the built in cron API but the reality is that it’s not only confusing and awkward to implement but once you’re complete you have to allow for a bit of latitude on the scheduling.

Take a look at scheduling a task in Wordpress. Basically, it works by adding a function to your activation hook, within a plugin, that like the below:

<?php
register_activation_hook(__FILE__, 'my_activation');
add_action('my_hourly_event', 'do_this_hourly');
 
function my_activation() {
	wp_schedule_event(time(), 'hourly', 'my_hourly_event');
}
 
function do_this_hourly() {
	// do something every hour
}
?>

Pretty simple implementation really though not very “cron” like in syntax. The important part is the call to “wp_schedule_event()” which takes 4 parameters (start date, recurrence, hook and arguments). According to the API manual the function:

Schedules a hook which will be executed by the WordPress actions core on a specific interval, specified by you. The action will trigger when someone visits your WordPress site, if the scheduled time has passed. See the Plugin API for a list of hooks.

The problem I had was that this function only allows for 3 options on recurrence; hourly, twicedaily and daily. I needed my function to run at a specific time. (It was EXTREMELY important that it ran during a specific interval.)

This isn’t to say that it’s not possible to schedule a task for a specific time; it’s just a pain in the ass. You have to write all the logic to determine when to add a new task and removing expired tasks. Ughh. To me the question becomes “Should I write a couple hundred lines of code or just add a single line to my crontab?”.

Crontab baby.