Web hacks - gzinflate and base64 encoding

A recent exploit I ran into dropped a remote administration console into a PHP script. I've seen similar exploits before, but this was the first time I had personally run into PHP exploit code nested in the script that used this bit of PHP:

eval(gzinflate(base64_decode('encoded file...')));

This is reasonably clever, as it keeps the file size down and makes the exploit a bit harder to figure out (should we call that insecurity through obscurity?). Vendors also do this at times to try to protect their code, although it is not a very effective reverse engineering prevention scheme - it keeps casual viewers from stealing your code.

How can you deal with this, especially if you're not a PHP wizard? Well, fortunately, the answer is pretty simple. A number of pre-built decoders exist, and my favorite of the day is from Steveandthesoftware. (the site is currently not responding, so you may have to check out the Google cache). There's another simpler script here, and you could always build your own if you're so inclined. Some tools also include base64 decoding - openssl does, as does the ever so useful Paros proxy tool. Even the L33t Key plugin for Firefox has base64 encode/decode support.

Today's lessons?

1. Use Tripwire or another file integrity monitor on your web scripts and other content that doesn't change often.
2. Have a known good, clean backup of those scripts.
   
3. Make sure your web server has permissions set appropriately on all of the directories - if your web server user doesn't need write access to the directory, don't give it!
4. Limit the permissions that your web server user (such as www or apache) has. Fortunately, this is the default for most modern servers. If your web server usage model permits it, an Apache chrooted jail may be a good idea.
5. In the event of compromise, rebuild if you can, and if you can't, make sure you're using those known good backups.