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