4

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."

Attachments phpbackdoor.jpg 25.38 KB

As Editorial Director and Managing Analyst with IT Security Thing I am putting more than two decades of consulting experience into providing opinionated insight regarding the security threat landscape for IT security professionals. As an Editorial Fellow with Dennis Publishing, I bring more than two decades of writing experience across the technology industry into publications such as Alphr, IT Pro and (in good old fashioned print) PC Pro. I also write for SC Magazine UK and Infosecurity, as well as The Times and Sunday Times newspapers. Along the way I have been honoured with a Technology Journalist of the Year award, and three Information Security Journalist of the Year awards. Most humbling, though, was the Enigma Award for 'lifetime contribution to IT security journalism' bestowed on me in 2011.

11
Contributors
10
Replies
45
Views
7 Years
Discussion Span
Last Post by Heinz Stapff
0

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.

0

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.*

0

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!

Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.