Aaron Saray has a post to his site sharing the "anatomy of a PHP hack" - the evidence that he found and pulled apart based on a recent hack he experienced.

It’s hard to come up with a title for this - but - basically I found some rogue code the other day that I thought was pretty interesting. I was fixing a “hacked” website when I came across the source of the symptoms of the hack.

He starts with the code he found in the hacked website, obfuscated to hide the true intent and how he disassembled it to find the true intent. He walks through the method he used to reverse the code ultimately ending up with a simple call to base64_decode a value that comes in from a $_POST request.

On his site recently Alex Zorin posted an article about shimming PHP for fun and profit making use of the runkit functionality to override some of the basic PHP handling.

I had spent a short amount of time profiling the application some months ago. By all indications, the framework upon which the site was built was doing something really stupid.

[...] For somebody who is comfortable finding and fixing hotspots like this, it sounds like a dream come true. Not so. A quick grep through the code indicated that that particular hotspot existed in at least a dozen different points in the code base. As my role in this scenario was an ops. engineer, touching the client’s codebase was a no-no.

He first looked into something he could add at the Zend Engine level itself but then veered more towards custom functionality that overrides some base64 handling in the language. There were some difficulties following this path so he shifted to another tactic - using runkit. He implemented this "monkey patching" solution using the runkit handling and integrated it into his client's installation reducing the load time by about 10 seconds on the largest, slowest request he could find. He also includes a link to the code if you're interested in seeing how he accomplished this optimization.

The Paragon Initiative has posted an article about cryptography, introducing some of the basic concepts and explaining why "you wouldn't base64 a password" to adequately protect it in your application.

If you feel that cryptography is a weird, complicated, and slightly intimidating subject for which your feelings might be best described as lukewarm (on a good day), we hope that by the time you finish reading this page, you will have a clear understanding of the terms and concepts people use when this topic comes up.

He starts with some of the basics around hashing (keyless cryptography) and the advantages/disadvantages of the method. He moves from there a step up and gets into secret key cryptography, using things like HMAC hashing to ensure message validity. The next move up is to secret key encryption, using some kind of "secret" as a part of the encryption process along with the right algorithm and mode for the encryption level desired. He also covers authenticated key encryption, public key encryption, shared secrets and digital signatures. He ends the post covering some of the common pitfalls of using cryptography in things like password storage, file verification and a reminder that encoding (like base64 encoding) and compression aren't encryption.

In his latest post Anthony Ferarra makes a suggestion about teaching developers how to solve problems via a "quick fix" versus educating them about the real problem: educate, don't mediate.

Recently, there has been a spout of attention about how to deal with eval(base64_decode("blah")); style attacks. A number of posts about "The Dreaded eval(base64_decode()) - And how to protect your site and visitors" have appeared lately. They have been suggesting how to mitigate the attacks. This is downright bad. The problem is that these posts have been suggesting things like "Disable eval()" and "Disable base64_decode()" as possible solutions. And while technically that would work, it completely misses the point, and does nothing to protect users

He suggests that developers shouldn't just look for a "quick fix" solution posted in a tutorial somewhere and go on their merry way. One danger in this is that those instructions could only be patching part of the problem, not all of it. In this case, the disable eval/base64 handling is only a code-level fix. If this exploit exists in your application, the attacker was able to get to the local file system - a much bigger problem.

Joseph Scott has a recent post to his site looking at the idea of stateless CSRF tokens and how to create them while avoiding the typical "store them in a session" mentality.

This is all fine and good until you want to avoid using PHP sessions. Perhaps you have several web servers and don’t want to deal with shared session storage. Or have servers in multiple data centers and don’t want to try and sync state across them. What ever the reason, popping a token into $_SESSION isn’t an option in this case. In short you want some sort of stateless CSRF token.

He looks at two methods to help get around this issue. The first method is based on known values that won't change very frequently (say, maybe 24 hours). His second method, however, has a bit more strength to it. His idea uses a combination of a key, the current time, a timeout and a known string of data - all base64 encoded.

In a recent post Marcus Bointon looks at a hashing method that's not one as commonly used by developers as the usual base64 - base-62 encoding that plays a bit nicer with things like URLs and emails due to the character set it allows.

There's a really horrible bug (though they won't call it that!) in Apache's mod_rewrite that means that urlencoded inputs in rewrites get unescaped in their transformation to output patterns. The bug actually remains unfixed, though a workaround first appeared in Apache 2.2.12. [...] Base-62 is interesting as it can be made safe for use in URLs, DNS, email addresses and pathnames, unlike any available encoding of base-64, as it only includes [0-9A-Za-z].

He originally wrote his own parser, but notes that now the BCMath and gmp extensions make it much simpler, just a call to gmp_strval with gmp_init. This method works, but it's still not quite all he wanted so he created his own encoder to do the job.

Evert Pot has a quick post on a handy little topic - making streams from strings with PHP (see some of it in action on Davey Shafik's blog).

There are situations where a string instead needs to be used, and for these purposes the data: stream wrapper is used. Initially I thought it was only possible to encode the actual string in base64, which I didn't like because of the added footprint. [...] Quickly checking out the rfc, it turns out that ';base64' can be omitted to just pass along the raw data, which makes a lot more sense in the context of PHP.

His example takes in an example string and pushes it back out the other side after base64 encoding and decoding it. Davey Shafik found a use for it in avoiding an eval call.

Davey Shafik has a helpful hint for avoiding one of the worst functions to use in PHP - eval.

There are a shed-load of ways to "eval()" code without actually calling the eval() function — usually done simply to avoid the use of the dreaded "evil()" function, but often times because the system has eval() disabled using "disable_functions" in php.ini. Here is another simple way to avoid eval() without writing out files to the filesystem

His example uses the streams wrapper to natively execute the code from a string variable as a data element, base64 decoded. It's more of a proof-of-concept than anything else, but its an interesting solution to a tough problem to solve at times.

Richard Thomas comments on a "funny little PHP 'virus'" that he's noticed coming to him via emails:

Got an email that claimed to be from my host, it used a generic return address and talked about security upgrades and such and how due to new policy to help keep a secure data center I was required to upload and run 1 of 2 files in a zip attachment, the first was a php file the other was an asp file.

Of course, it wasn't from the host, so he investigated a little further to find out exactly what was going on with the file. Basically, it was a modified nsTView file with some added emailing and password discovery code. The code was "hidden" though - through a base64_encode call on one side and then decoded it on the other to cause the server to execute the code. He even posts and example of what the base64ed code might look like.

Richard Thomas comments on a "funny little PHP 'virus'" that he's noticed coming to him via emails:

Got an email that claimed to be from my host, it used a generic return address and talked about security upgrades and such and how due to new policy to help keep a secure data center I was required to upload and run 1 of 2 files in a zip attachment, the first was a php file the other was an asp file.

Of course, it wasn't from the host, so he investigated a little further to find out exactly what was going on with the file. Basically, it was a modified nsTView file with some added emailing and password discovery code. The code was "hidden" though - through a base64_encode call on one side and then decoded it on the other to cause the server to execute the code. He even posts and example of what the base64ed code might look like.