"Marge: Cmon, Homer, Japan will be fun. You like Rashoman.
Homer: Thats not how I remember it."
The 'Net is quietly abuzz with chatter about Santy. It's a worm -- an old-school worm, that travels server-to-server, running a single exploit against one of the server's exposed services. But there's something "new" that scares people about Santy, Santy.B, and all its forthcoming incarnations: It can "discover" likely targets using internet search engines. Santy's success [re-]proves two points that have been made over and over again over the years: The more services you expose, the more vulnerable you are; and as you make it easier to code software, you also make it easier to code malware.
Security in computing, as in the non-virtual world, ends up being largely a matter of how many ways there are to get in and out: If you've got lots of doors and windows, you have poorer security. You can qualify the analogy somewhat, but that's pretty much how it works. Santy works because there are not only lots of doors and windows, but also because some of them aren't as well secured as they should be -- and because some of them advertise too much about themselves. (But that's another topic for another time. And none of this should be taken as excuses for following the "one strong door" model.)
Santy's first manifestation used Google to locate likely targets; now it also uses AOL and Yahoo search interfaces. It finds its way onto a system, patches itself into vulnerable code in certain versions of phpBB, and then proceeded to run Google searches for certain strings that would appear in those vulnerable versions of phpBB. This worked because Google has a stable and easy to use API -- really, from the perspective of Santy's author, just a standard format for input and output -- and it doesn't make any distinction between clients that have a person looking at the results and clients that have a machine looking at the results. As much as I'm wary of Google in general, this is a perfectly right and proper way for their software interfaces to operate, and they're not any different in this regard from any other search engine. Or any open bookmark repository, for that matter.
I repeat, this is old-school, albeit updated for new times: In 1994, someone might have written something analogous to this to use Gopher or WAIS or Archie. They'd have had to be smarter coders, and because some techniques hadn't been pioneered yet, the codebase would be larger and clumsier. But it could have been done, and probably was. I knew guys who thought that way, back in The Day. But the community of people who'd have been impressed was smaller, and frankly, servers were inherently more secure by virtue of simply having fewer exposed services.
The main thing that's actually changed is that it's now a lot easier to code this stuff. A mediocre scripter could hack together Santy in a week or less of spare time; a good coder in just a few hours. Back in the day it would have taken much more skill and time. The target would have been more esoteric, and the task would have taken much more technical expertise. There was no PHP or phpBB; there were no bulletin board systems to exploit. But it would have been possible to do something analogous to Santy in 1994. Not to slight the effort: What's needed in both cases is to have had the ideas about how to design it, which is a non-trivial point.
There has been a call for Google to "shut down" this vulnerability -- for it to block Santy's searches. That call was, frankly, ignorant: Yes, it would be possible for Google to play a game of cat and mouse with Santy coders (and it appears as though they may have been bullied into doing just that), but that would be bad for two reasons: First, because it would create an "artificial selection" environment in which Santy-coders would be forced to evolve things like source IP masking, metamorphic user-agent strings, and Bayesian pattern-matching for target identification thus indirectly causing the other side to get better; and second, because it's an unwinnable battle, and anyone smart enough to get hired at Google already knows that.
To be sure, poor security practices are also partly to blame. If I read the advisories correctly (and I may not), you have to configure phpBB in a fairly non-secure way to be vulnerable: Namely, you have to make your comment-posting forms world-accessible. That's common practice on boards that allow anonymous posting; there are obvious downsides to dis-allowing anonymous posting. It's a baby:bathwater conundrum, in that you throw away some of the liveliness and spontaneity of your board if you don't allow anonymous posting. (BTW, to forestall concern, Antikoan.net is not vulnerable to the exploit used by Santy, since our hosting provider has already installed the relevant PHP security patches.)
And the commodification of hosting plays a huge role in exposing vulnerabilities, though it can also help alleviate them. From the mid-'90s through the present, hardware and software commodification have conspired with consumer expectation and economies of scale to thin the margins on hosting to a hair's breadth; if a hosting provider spends two minutes a day of his own energy on a single customer, that's two minutes too long for him to be making a profit. So corners get cut, processes get automated using home-brewed scripts that aren't debugged. Best-practices for security get ignored because they make things harder to manage. The same commodification, though, has driven the development of highly automated hosting maintenance systems that bake-in things like security best-practices and software version control. There's distance to go, but it's getting better very rapidly.
Final aside: Santy is, in a way, the very worst kind of robotic exploit tool, because it's scripted, not compiled. Its instructions are available to any reasonably competent sysadmin who happens to get infected. And since it's PERL exploiting PHP, the development and execution environments are nearly ubiquitous, and the exploitable platforms still richly plentiful. phpBB may be the first exploit target, but it won't be the last; my quick research indicates that the most common family of OSS CMS systems may be vulnerable at its core, and almost certainly is in some of its more popular third-party modules. (The more frightening prospect is that one of those modules is now without a maintainer, and so if exploited, would remain exploitable. I'll leave my conjectures vague for the time being because they're still just conjectures, and anyway I wouldn't want to give anyone ideas.)