a customer of mine was running a slightly older kirby version (i think it has been 2.4.1) and his hosting notified him that a malious file has been found on his webaccount giving information that the files both came with this type of content
Web shell:PHP/shell.generic (Web-Shell - Generic web shells)
web/assets/b.php
web/b.php
i have read all changelogs which came up to 2.5.8 to find out if it could have been something which has been found and fixed in the meantime but according to the changelogs the only real security concern has been cross site attacks from within a panel user uploading prepared svg file.
there are no panel users other than me and him and i could rule out the svg file part.
the site is quite basic, there’s frontend form which does not include any sort of file upload whatsoever so i am looking for some indication what could’ve been the issue there. i obviously updated to 2.5.8 in the meantime but i am not sure if that has been the problem.
The provider also mentioned it could be stolen login details and whatsoever. What are other ways to get these kinds of malious attacks injected? Are there chances that it’s rather a stolen password or something entirely different. For myself i am rather aware of security and using secure methods like password manager etc.pp.
Seems like FTP and SFTP both are active and can be logged in on. I am not sure why, but seems like SSL / https is also not active (anymore? maybe was never though)
Otherwise there’s just kirby.
Do you think generally speaking kirby can be ruled out in terms of core, toolkit, panel?
Also the point of 2.4.1 being used?
I’d say in many/most cases an insecure FTP account is the reason why this happens. Of course, if you enter passwords into a non-https webform, anyone can read this and this is a security hole as well. As soon as you use a login form on your website, your site should be secured via HTTPS.
Generelly, I would never rule out anything. It’s just a question of probability.
I went to a security conference once funded by my workplace, were an expert demonstrated just how easy it was to break into a site and inject files onto a server by using specially crafted javascript strings executed through submitting a contact form.
This has certainly happened to the Wordpress sites i’ve worked on in the past (one had over 100 hidden links of an adult nature injected into a page through a form powered by a plugin).
Don’t suppose you have any custom contact forms on the site that may have provided a hole to get in?
Definatly disable FTP and change all your passwords though, and enforce HTTPS always
If it was me, I would be completely deleting that site right now from the server to get rid of all the folders and set it up again from scratch with new accounts, and at a new path on the server. your host identified a couple of files, but that may not be the end of it. Who knows what else is lurking the folder structure.
Is this site on shared hosting? It’s possible your site wasn’t comprised at all, but another site on the same box was and the malicious code has been “thrown over the fence” to other sites on the box. This is why don’t use shared hosting, ever.
Anyway, you now will have to erase everything and set it up all new. Luckily, if you have a recent backup, that will all be done within a few minutes. Just make sure to use HTTPS if you use the Panel, and make sure to transfer data via HTTPs only and disable FTP in all cases.
As I said above, the most likely scenario is that someone got in via FTP. But I don’t think you will be able to find the root cause. So your main task now is to make sure that you block all possible ways in that are under your control.
thanks for your reply sonja, i have already stumbled upon the owasp one, as well as the security guide and read some about the xss methods and alot more.
i have checked everything i could and made sure pressure the customer to finally transition to ssl and a secure method for ftp. it has been on his list for more than a couple of months and seems the hosting isn’t very much efficient in doing changes.
so most of the things which were mentioned should be adressed by now.
Make sure to double-check the file permissions. Especially on shared hosting the code could also be injected from another account on the same server, when the permissions are not strict enough. Make sure to set long and secure passwords for SFTP and the panel. I often find installations with 6 char FTP passwords. It’s so trivial to hack this. Especially if the FTP username is the domain or something like ftp.yourdomain.com.
Please let us know if you find anything else that could be a hint to what it was!
The esc() helper is not intended for input sanitizing, but for escaping HTML, XML, CSS and JavaScript output.
There are other ways to check user input, like filter_var() etc.
You don’t want to escape and store something like <script>deleteContent()</script>. It makes no sense.
You want to block that entirely from getting through, right?
And if something does get through somehow, we can prevent it from doing harm on the frontend with esc().
