By Harry Fuecks

PHP Worms: Santy / Perl.PhpInclude – ModSecurity

By Harry Fuecks

Looks like someone’s finally got nasty, in writing code which targets potential mistakes people often make with PHP. Although you may be on holiday, recommend giving these some thought at least and, if in doubt, do what Christian as done and take it offline until you’ve got time to deal with it.


Hopefully you’ve already picked this up but if you’re using phpBB, you should to upgrade to 2.0.11 (see the announcement).

The reason? The Santy Worm. This one even made the BBC’s website (ironically, probably the first time for PHP or a PHP app).

There’s been some confusion surrounding Santy, such as this announcement, which suggests the worm exploits a vulnerability in PHP itself. Derick cleared this up here – phpBB was also exposed to a problem with PHP’s unserialize() function (fixed in the latest PHP release) but this was not what the worm uses. Ilia discusses the unserialize() vulns here.

The most considered and up-to-date information I’ve found so far is available here. There’s now more than one version of the worm out there and the latest, Santy.e, also being called the Perl.PhpInclude.Worm (it’s apparently not related to Santy).


The Perl.PhpInclude.Worm seems to exploit a common potential vulnerability / mistake, which I described (last April 1st) here. Make sure you read this: 4. Remote Files and take this very seriously.

Should be possible to knock up a shell script to scan a filesystem for code that could potentially contain such issues, grepping for include statements (and similar) which contain PHP variables. Out of time for today but will try tomorrow (unless someone gets there first).


Been pondering a blog / discussion on ModSecurity for a while now. This makes me think it’s time to get a move on. I owe it’s author Ivan some emails – ModSecurity came up at OSCOM.4. This is just some quick notes…

First I highly recommend that both web hosting companies and developers of projects like phpBB that look at ModSecurity. Ivan has already blogged what may a filter for Santy here.

Some key things about ModSecurity (referring here to the C version, not the Java version);

– It’s an Apache module

– It filters incoming requests first, before Apache does anything else with them (such as hand off to PHP)

– It’s rules-based and rules can contain regular expressions (among other things)

– You can have it perform very fine grained filtering (e.g. filtering a single GET variable called ‘highlight’)

– Configuration can be made in httpd.conf and .htaccess files

– It can work in something like a “permit all / deny some” or “deny all / permit some” modes, similar to other Apache rules

– It really is the simplest thing you can possibly do

– There’s a tutorial by Ivan on O’Reilly here

Potentially hosts can use ModSecurity to screen all requests for likely exploits such as Javascript XSS and things like the Santy worm (permit all / deny some) . Developers like the phpBB team could also publish “valid request signatures” for their applications – everything they regard as valid input (deny all / permit some).

  • Thanks for the heads up. I notice this script on a exploit site today. :S

  • evolve

    ModSecurity is really key for webhosts who use apache to have.

    Google also helped the spread of the Santy worm by preventing its search engine for being used to find websites to attack. They blacklisted a number of keywords which the worm was using to find targets.

  • so,its only a phpBB thing? just wondering what the exploit is, or if there’s a function in specific they are using. got +10K visitors over X-Mas Weekend, which is a little unusual, but my site isn’t defaced (yet).

  • so,its only a phpBB thing?

    The phpBB vuln seems to have been related to highlighted words passed from searches(?). I presume this diff was the fix.

    The include worm is different though and not specifically targetting any application. The version here looks to pull a list of pages with ‘.php’ in the URL from Google and Yahoo modify the GET query string and replace what would become PHP variables with a link to a remote site (which I guess was hacked in advance). One such site I saw in a log seems to have been taken down on the 25th, thereby “neutralizing” worms using it.

    Bottom line is if you have code like;

    // Validate first!!!
    include $_GET['page'];

    You could be in for trouble (depending on PHP configuration).

    This blog suggests that, this time round, there’s no need for panic. At the same time, this is the first serious attempt of this kind. There’s room to be “smarter” as well as target other oft-installed PHP-apps. Expect we’re going to see more of it.

    MOTD: Validate all incoming data. Anything you get from the browser cannot be trusted.

  • why would webhosts not install modsecurity? Overhead?

  • why would webhosts not install modsecurity? Overhead?

    Think the main thing is ModSecurity is still fairly new – think the awareness isn’t quite there yet. Overhead could be an issue although reading the ModSecurity docs suggests it shouldn’t. It probably (Ivan can no doubt answer that) needs a larger user base before it’s possible to consider performance in detail.

  • Richard Thomas

    Someone is limiting/spamming that channel to prevent it from getting a lot of connections while they try to get the channel killed. Thats the only reason the worm isn’t spreading like wildfire

    At least this is what I saw in one of the reports somewhere

  • Actually, phpBB had a similar type exploit a few years ago — v2.04 or thereabouts. That’s when, as a Server Admin, I started paying more attention to the security within PHP itself.

    By having the following in a Server php.ini file:

    disable_functions = shell_exec,system,proc_open

    all PHP scripts have very good security.

    Everytime I see this error showing in the Server Error logs:

    PHP Warning: system() has been disabled for security reasons

    it gives me a warm feeling knowing Clients scripts are safe and no defacement has been done, regardless of any security weaknesses within an individual script.

    Tis only one part of an over-all security strategy for any Server though, and as mod_security becomes more popular, is an excellent security addition.

  • Stephen

    Well our server has been compromised in the last week or so. On Friday they managed to use it to send a whole load of spam emails and that gave the game away as server usage rocketted. We have been noticing very high traffic since 9th Jan anyway.
    Doing some digging now reveals that it got compromised via the include hack into phpBBs viewtopic.php script. I am just decoding the system calls to see what happened.
    I think the mistake is to assume that the vulnerability is with the urldecode() function. That is simply the phpBB guys fix. i.e. to remove it – as far as I can see. No. The real problem lies with the preg_replace(#….#e,,) call that uses what gets passed by that variable in the viewtopic.php url. The ‘e’ option on preg_replace causes the second parameter to act like a function on the first. So they simply include a system call in there with the execution vars encoded as chr()s.
    So the rule seems to be for php coders nothing to do with urlencode, etc. but don’t use preg_replace with the ‘e’ option unless you check what it is you are executing!

    Now back to our server. What really troubles me is that not only did they gain access to /var/ where they can upload files and execute as user apache, but they also managed to get root access. This is the bit I can’t work out. Do I take it that they managed to run one of the latest known compromises for “root as local user” scripts? I see there is one for SMP kernels on Linux. We were using Mandrake 9.2 with SMP and looking at other sites it seems that there is just such a script for our kernel.
    Has anyone else had this? Apart from that no pages defaced etc. But we will need to reinstall the server, change all passwords now, etc. which is a real pain.

  • Gavin C

    It stumped me for a while too. It’s just a short script running as the apache user, no real exploit.
    it tricks phpbb into running something like this:
    exec (wget some perl script; perl /var/the script)

    It does a trick where it disguises itself to look like an httpd process in the list. this makes it look like it has root and started a server. It uses wget to download some scripts into var which it is allowed to do running as apache. then it runs the script with perl. The quick way top stop it is to rename wget. then upgrade phpbb.

Get the latest in Front-end, once a week, for free.