Re:Pear.php.net shuts down after maintainers discover seriou...
by _cereal on Thursday January 24, 2019 @09:24AM
(#18988875)
For "known good" folder, a git repository may help, at least to restore a clean version of the code.
Re:Pear.php.net shuts down after maintainers discover seriou...
by meowface on Thursday January 24, 2019 @11:44AM
(#18990282)
Probably preaching to the choir here, but for those who are unaware, be sure that .git directories are not accessible by web clients. It will lead to source code disclosure, and if you've checked in any secrets, credential exposure as well.
Re:Pear.php.net shuts down after maintainers discover seriou...
by aaronmdjones on Saturday January 26, 2019 @01:27PM
(#19007581)
That and if the webserver can write to .git it can also invisibly modify the history to ensure that you continue to check out the backdoored code no matter how far you go back.
Re:Pear.php.net shuts down after maintainers discover seriou...
by acdha on Thursday January 24, 2019 @08:50AM
(#18988600)
The challenge for comparisons is doing it all offline and indistinguishable from user activity - I’ve seen cases where the attacker updated tripwire, rpm/deb sums, etc. or only presented the payload to a specific process, requesting IP not on the local network, etc. In this case I’d want something like a random process where a new EC2 instance does a install so you could make it a lot harder to cloak the attack because that’s also what many targets will do.
Also not a bad idea to have some kind of file compare against a "known good" folder of your site(s) to determine if any files have been modified or added, such as webshells.