NYCPHP Meetup

[Daniel Convissor]

Hi David:

On Tue, Mar 27, 2012 at 10:47:16AM -0400, David Mintz wrote:
> 
> Yeah, I assembled the regex based specifically on the malicious code that I
> was looking at in all my files. I suppose the trick is to fashion a regex
> that catches an actual eval call inside php tags -- there's  always a
> chance that the string "eval" is is somehow legitimately contained inside
> some php tags.

Sure, that's why you identify the files using grep, then do targeted
editing.  If all uses found need to be blown away, then you can use your
regex search and replace.  Otherwise handle the "good" files manually and
direct your regex search and replace handle the rest.

Oh, and <?php tags should not even be part of the regex.  There can be
other code between the opening tag and the injected code.


> Except when it really needs to, like for writing data to a file-based
> cache, or accepting file uploads. How do you recommend handling those cases?

Specific directories can be left writable.


> I have been wondering, why not chmod ALL your php files to 400? Indeed I
> did this with one site after my infection, but not the several others. Then
> I got hit again, but the site whose php files were 400 was not affected --
> probably not a coincidence.

Probably?  Certainly!


> It's perhaps a bit of an inconvenience when you
> need to update/overwrite, but I see no reason we can't relax permissions
> temporarily for code deployments and reset them back when we're done.

That's why you automate your deploy process.  Easiest way is via shell
scripts.  chmod writable; update files; chmod readable.

--Dan

-- 
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
            data intensive web and database programming
                http://www.AnalysisAndSolutions.com/
 4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f: 718-854-0409