Simon Willison’s Weblog

Hacked for Spam

From the New York Times:

Computer security researchers have been watching the evolution of remote-access rogue programs as they have become more common and have put more machines under the control of hackers. Programs like Sinit infect target machines and surreptitiously open back doors that allow outsiders to control the PC’s. The rings of infected computers have been used to send spam, to present online advertisements for pornographic Web sites or to trick people into giving up information like credit card numbers.

In fact, at least a third of all spam circulating on the Internet is now sent from or relayed by personal home computers that have been taken over, said Jesse Dougherty, director of development at Sophos, an antivirus and antispam company.

Emphasis mine. Of course, whether or not you want to believe a director from a company that directly profits from people’s fear of security attacks is up to you. That said, I’ve seen plenty of supporting evidence in the past few months that indicates that spamming is now the number one reason that a cracker would want to take over a PC, not least this Wired article.

Continuing on the same theme, The Rise of the Spammers is a fascinating article by David Barroso Berrueta describing how one of his servers was turned in to a spam relay after being compromised through a vulnerability in a PHP script. The technical details are intriguing; the attacker downloaded and uncompressed a daemon which then communicated with another host using an extended version of the SMTP protocol, receiving spam email bodies along with lists of addresses to send the spam on to.

Let’s talk about the PHP vulnerability in question: yet again, it was the classic problem where an attacker can instruct PHP to download and execute code from their own server by feeding in a query string parameter that is passed un-checked to an include() function call. While there are a number of steps that can be taken to deny this kind of attack, it unveils a fundamental problem with PHP itself—that it will execute code retrieved from a URL in the first place! This feature should be removed from PHP—it has almost no purpose in the real world aside from allowing servers to be cracked in to. The feature exists because PHP has the extremely useful ability to open remote files over HTTP. Unfortunately, this feature extends to the include() and require() functions which will execute any PHP code in the file passed to the functions. The most obvious solution to my mind would be for these functions to refuse to execute PHP in files that were opened via HTTP. I have no doubt that this would involve an ugly hack on behalf of PHP’s maintainers, but I believe the number of security problems it would solve would be well worth the trade-off.

Incidentally, I know you can disable opening files over HTTP and I know you shouldnt allow the direct creation of variables from the query string in the first place. The problems here are two-fold: firstly, opening files over HTTP is actually a very useful feature, one that would be all the more useful if it didn’t carry the risk of executing arbitrary code. Secondly, the problem is mainly down to third party software which often requires insecure PHP settings (such as register_globals) in order to work.