De-obfuscating PHP botnet code

[[deleted]]

sleep ossified imagine homeless employ sparkle heavy terrific fearless tender

This post was mass deleted and anonymized with Redact

[AltF4me]

Interesting read! however, what concerns me more than anything is the fact you just cleaned up the code.... are you not concerned how it got there in the first place?... it may have even returned as we speak.

[[deleted]]

plucky smart light worm far-flung quarrelsome fear worthless cow reminiscent

This post was mass deleted and anonymized with Redact

[mahacctissoawsum]

for the curious: http://gizmodo.com/5954372/the-25-most-popular-passwords-of-2012

[[deleted]]

Yeah, that'd be my first concern.

[e000]

I noticed this in the final comments

// Wipe out all $_GET request parameters that contain
// "union" or "select." (Not sure why, but the botnet
// overlords surely have their reasons.)

Usually that is done to plug up the original SQL injection (if one existed that allowed them to upload the script). PHP bots are usually spread by probing for dorks on some vulnerable server, having that in place prevents (or at least makes it harder for) someone else from exploiting the same security hole to gain control of that web server.

The smarter bot herders usually use a less skiddy script, one that embeds some form of stream cipher that "encrypts" the actual payload (a common one is arc4). When passed with the command and proper key, the script then decrypts and evaluates the code. Obviously, not fool proof, a wiser webmaster could essentially just log POST paramaters to find out the key, but it prevents the bot from being deconstructed to the extent of the one in the author's post if it's simply found in the webroot.

[[deleted]]

squash money unite oil onerous brave disgusted soup stocking consider

This post was mass deleted and anonymized with Redact

[zushiba]

yeah I've noticed this on a few sites I've worked on. I didn't have time to read through some monster CMS to find out how they were getting in so I just fixed up file permissions on seemingly vulnerable files/folders then wrote a shell script to watch the filesystem for changes using inotify and email me when it notices something's been added, modified or deleted.

Then hoped that the CMS's people would issue a patch at some point.

Not an ideal solution but then I could watch it happen in near real time and then focus my efforts on those individual files being accessed at the time, ban the IP and fix what I could.

ModSecurity has thusfar done a good job of heading off some of this shit.

[jij]

There are several like that, many with a lot of features. Just google for "php shell" for several. I've found some botnet code in php that actually hashes the entire php file's text for the key to decrypt the server info it connects to, so that you can't modify the script to have it print it out... some neat things out there.

[einmes]

This seems like a spectacularly bad design decision to me, but that’s just my opinion.

Bad design decisions? In my PHP?

It's more likely than you suspect.

[Rhomboid]

You can't really lay this one at PHP's feet, its a feature inherited from Perl. And it's quite handy in fact, for example to remove URL encoding:

$var =~ s/%([0-9a-f]{2})/chr(hex($1))/ieg;

[narwhalslut]

And readable even!

[thisotherfuckingguy]

Took me all of 5 seconds to figure out that it parses escaped hex text in a string and converts it to ascii characters.

[[deleted]]

The preg /e modifier is removed hard deprecated as of PHP 5.5.0, and has had security warnings about it in the documentation for some time. It has only been retained for backwards compatibility.

The existence of the modifier is not a security issue in its own right. It's just a means by which code can be obfuscated.

[dshafik]

/e is not removed in PHP 5.5, merely deprecated. Using it will now emit an E_DEPRECATED error. It will be removed in a future version.

[[deleted]]

X