Everyone loves PHP these days it seems, and that includes the bad guys. So it should come as no surprise to learn that yet another remote access Trojan written using PHP has appeared. However, the fact that this particular bit of PHP backdoor code comes complete with a second, hidden, backdoor within it certainly was surprising to the security researcher who found it. DaniWeb has been talking to that researcher to find out more...

"Is there no honor among thieves anymore?" asks Andrew Brandt, the Lead Threat Analyst for security specialists Webroot, when disclosing the details of his PHP double backdoor discovery . It's a good question, albeit one that just begs an answer of 'was there ever?' to be fair. Being a threat analyst for a leading security vendor, Brandt spends a lot of time picking through exploit code. So it was not unusual for him to find himself examining the internal workings of a PHP remote access Trojan that loads into memory on a target computer when the victim strays upon the iframe which points to the PHP script sitting embedded in a web page. "The code is nicely appointed with such desirable features as the ability to execute shell commands on the host server, send a flood of data packets at another computer, and scan remote computers" Brandt reveals.

In fact, it's fairly standard bad guy stuff, albeit well written bad guy stuff. Until you start to dig a little deeper into the code, as Brandt found himself compelled to do, and find another backdoor embedded within the backdoor itself. "Someone’s bugged this bug with another bug" Brandt says, adding that the second chunk of code looks like a blob of base64-encoded garbage but decoding the base64-encoded text, set into the $dc_source variable, reveals that the bot writes out the commands into a Perl script to execute them. Invoked during the PHP bot's loading routine this commands the original bot to connect to a different control server, operated by another criminal enterprise to the ones that coded the original Trojan. No honor among thieves indeed, using someone else's code and distribution network to spread your own exploit around. You've got to admire the chutzpah of these guys. The 'Data Cha0s Connect Back Backdoor' is not exactly new, it has to be said, as a Google search reveals it first being seen as far back as 2005. The fact that it is still appearing in remote access Trojans being coded and distributed today is, however, rather worrying and suggests the gang behind it are still going strong.

DaniWeb spoke to Andrew Brandt and asked just how dangerous PHP is in the overall security threat landscape scheme of things?

"Many very useful websites or content management systems are built on a PHP framework. That said, PHP can and has been used as a tool for malicious activity , just like Javascript. PHP backdoors, bots, and download code has been part of the threat landscape for some time. There are hundreds of different bots, backdoors, and other malicious server-side PHP code floating around. But this isn't a problem with PHP, inherently, just as Windows malware isn't a C++ or Delphi problem. Malicious people will use whatever tools are at their disposal to engage in malicious activity. PHP happens to be a particularly powerful and useful tool, but whether one uses it for good or evil depends on the human doing the coding at the keyboard" Brandt says.

So what advice does Andrew have for DaniWeb members looking to mitigate the risk?

"There are two people who face risks from this kind of malware: The owners/operators of websites or web hosting companies, and the hapless web surfers who stumble upon these pages" Brandt replies, continuing "Website owners or hosting companies need to enact strict password policies that require users to create passwords of adequate complexity, and to change those passwords regularly. Passwords shouldn't be allowed to persist for longer than 90 days, to mitigate the damage that can be caused when, for example, the admin who normally uploads content to the server finds their computer compromised by the Zbot, Spyeye, or Koobface phishing Trojans. Anyone who uses an FTP client application on Windows needs to be aware of the special level of risks and threats posed by password stealing Trojans. Computers which are used for the purpose of maintaining websites or web content need to be protected with extra care, and not used for casual surfing, checking personal email, logging in to Facebook, or "letting the kids play games."

What about the web surfers? "Web surfers should protect themselves by using current, up-to-date antivirus, as well as some sort of scripting controls on their browser" Brandt insists, concluding "businesses can use filtering solutions to protect company computers from various attack scripts employees might stumble upon. Firefox has a great third-party add-on called NoScript which, by default, prevents scripts from running in a web page unless the user has selectively chosen to enable a particular site's scripts to run. This can, for example, prevent a rogue script hosted on an advertising server from running, while permitting you to use your favorite news or information website the way you normally would."

Thanks for your post.

Hi Dani,yes you are right. PHP is now a booming technology like .net,java etc..I know some basic concepts only in PHP but this(PHP backdoors, bots, and download code) concepts are new to me and very happy to read your post. Please do keep posting more in PHP,because i became fan of you so iam going to learn more about PHP.
http://godwinsblog.cdtech.in/2010/11/microsoft-now-supports-php.html

cwarn23 commented: Thanks for the comment :) keep on posting +12

Everyone loves PHP these days it seems, and that includes the bad guys. So it should come as no surprise to learn that yet another remote access Trojan.

Everyone loves PHP these days it seems, and that includes the bad guys. So it should come as no surprise to learn that yet another remote access Trojan.

Please don't bump old threads as I am sure this has been fixed in PHP 5.3.*

Please don't bump old threads as I am sure this has been fixed in PHP 5.3.*

Genius bump-er hunter ;)

Thanks for your post. is idea

Can someone confirm this? Interesting though.....

Thanks pro

Member Avatar
cuonic

This is almost 2 years old now... No need to keep bumping it. D:

I thought there was a Class array of permited Ajax queries that prevented access to the site even if they had your password? Even an array of permited script files might help. Any advice on demonstration articles addressing these arrays would be appreciated!