zlacker

This smells of legacy PHP where any PHP file uploaded to a web-accessible folder can be executed.

>>Nextgr+(OP)
Likely, I've unfortunately had the displeasure of being a victim of that, probably an off-the-shelf scanner that exploited a Wordpress weakness.

That said, I do think PHP software should be distributed in such a way that the files are both locked for editing by the PHP process itself, and verified regularly. I've been using XenForo on my website for a while and it's giving me e-mail warnings that a file has changed (I did a customization), so it does exist.

But yeah, that particular category of error can be mitigated via config; disallow PHP execution in an upload folder, disallow PHP to add or edit files in the application folder, etc.

>>Cthulh+Ok
The main thing I do to avoid this is to host files on a separate server w/o PHP or a block storage service like e.g. S3 or B2. Make sure the domains are different too so you can't steal cookies.

You can also run a ClamAV scan to catch very obvious threats.

>>Cthulh+Ok
Modern PHP frameworks solve this problem just like the other languages solved this problem from the beginning - any inbound HTTP request goes into an entry point (the HTTP router library) which then loads the different classes and dispatches the request accordingly. The web server never executes anything but the entry point PHP file, regardless of what path the request is actually for.

The problem is all the legacy applications which are a mess of random PHP files and rely on the web server itself to dispatch requests based on the path of the file - in this case any PHP file can get executed if it happens to be in a location served by the web server. Rather than disallowing PHP execution in select folders, how about allowing PHP execution only for specific paths - those that you expect incoming requests to hit? That way no malicious code can run unless it manages to overwrite an existing file.

>>Nextgr+(OP)
The article mentions a compromised user account so the attackers were probably able to just upload files directly through the compromised hosting account. Plus what's interesting is they don't mention the server itself being compromised. I'm wondering if this was a permissions issue that allowed the attackers to traverse directories on the server to the other hosted sites.

>>Nextgr+(OP)
Or a sqli in the client portal?