Just started using Grav to build a site for a client and I’ve been having a weird recurring issue. Every day or so I get an error 500 while trying to access the site, and I’ve managed to trace it to some weird code that keeps getting added to index.php, right before the credits and namespace declaration:
I delete it and the site works, but it keeps coming back every day. It’s slightly different code every day too. I’m not sure what’s going on. Here’s a list of plugins I have installed:
Would love any advice on how to solve this
My first thought is that your server is compromised. Nothing should be modifying your index.php file.
If you investigate and find it’s via a Grav vulnerability, please report it using the process described in the docs (email to email@example.com in first instance).
I agree with Hughbris. It looks like code that is deliberately obfuscated, which there is rarely a legitimate reason to do so. The encoding isn’t consistent, but it looks like it’s trying to include a composer bundle, which could likely be malicious code.
Deobfuscating the code online renders:
Does this ring a bell?
This is a common injection-attack, that typically stems from compromised access to the server. I’ve seen it most commonly with regular FTP-credentials being sniffed in transport, and easily remedied by enforcing all server-access through SFTP with key-auth. None of your plugins have known flaws that would allow this, nor does Grav Core, so start by purging all accounts with server-access (through FTP, SSH, other scripts that may allow direct-file editing) and reinstall Grav with plugins. Enforce a strict policy of FTP through SFTP with a key-pair for access, and limit the amount of users with this to the bare minimum.
The code tries to have the server execute remote scripts, typically hidden behind “regular” files, which composer/ca-bundle is, but a normal installation of ca-bundle does not include
.43fa9ccd.ico – showing that it was placed there maliciously. Further, you should not be using or allow root access, and ideally keep executable files – such as PHP – locked behind permissions so they are not editable by general server-users.
@pamtbaau haha, using bacon ipsum for filler text.
@OleVik I use RSA keys for my server with root disabled. Maybe I have a bigger problem.
Thanks for the insights
@cactus Don’t forget to come back for saying us if you solve your problem and how. I’m interested in knowing how you fixed it.
I solved it by moving servers. I neglected to keep my existing server up to date for 4 years, haha. Been putting it off for a while but now I have an even faster and more secure stack.
That is a pretty big factor, there’s endless patches to solve security-issues allowing unwarranted access in operating systems, as well as for PHP and the hardware-level (most recently Spectre and Meltdown). It’s a benefit of shared hosting that the good ones typically keep up-to-date and on-top of things. On self-managed servers/VPS, we’ll have to be ever more vigilant ourselves.