2

I was unfortunately on holiday on the week of drupageddon / drupalgeddon / security advisory SA-CORE-2014-005. So my site was a week without having core updated/ patch applied at all. I started off reading through this post and, apart from the Hacked module which I couldn't understand and therefore didn't try, nothing seemed to have happened. Nothing seems to be a breach, but as I read - that's the point... So generally speaking I'm preparing to rebuild the server, but in all this it will take ages as I'll have to check through all the user submitted data. How is the hack able to lead to everything possibly being vulnerable? Looking through the permissions the only things that are owned by "apache" are the "sites/default/files" files. Do I need to rebuild the server?

I updated core immediately, then used the Drupalgeddon module which found nothing (and again found nothing just now):

"Site did not test positive. Good luck!                               [ok]"

I checked through the live source against our development repository and I couldn't see anything obvious that was suspicous.

I used Toad for MySQL to do a comparison of my live db with a dump of the database before the 15th of October and that did not show anything that I thought might be a problem. I kept doing what I was shown (!) in terms of permissions:

Group: root[0]; Owner: root[0]; Octal: "0755" for

  • /sites/all/modules
  • /sites/all/themes
  • /sites/all/libraries

Group: root[0]; Owner: root[0]; Octal: "0444" for

  • settings.php

Group: root[0]; Owner: root[0]; Octal: "0644" for

  • all root of web directory stuff like...
  • /install.php
  • /index.php
  • the files within the other folders off the root of the web directory

The folders:

  • /themes
  • /scripts
  • /includes etc.

have Group: root[0]; Owner: root[0]; Permissions: Octal:"0755"

Which I thought (and which is why I deliberately kept it like that) made everything quite locked down in terms of file access and permissions etc.

So after all this I was struck with a similar scepticism as this article on ZDNET.

Any suggestions? Do those permissions/ ownership help to protect? Do I really need to rebuid? The latest claims are if you didn't update within 7 hours, you've been hacked. The sites are actually fairly new and atm get roughly 5000 sessions a month. Also, coincedentally, I removed user/register to prevent spam because our setup uses a bespoke arrangement for registration.

Improve this question
6
  • It is best to keep questions separate. There are 2 questions here: are my file permissions good? Do I really need to rebuild. The second one no one here can possibly answer because we don't have access to your server to review the site, we know extemely little about your site, your server, etc.
    – rooby
    Nov 3, 2014 at 10:37
  • I included the permissions to give the context. I am ignorant of the link between SQL injection and the October exploit and precisely how one is then able to somehow take over a website, like a stealthy ninja leaving no trace.
    – ja_him
    Nov 3, 2014 at 10:40
  • There are many ways someone can take over your site or do other bad things to your site via this SQL injection bug. A lot of the possibilities have nothing to do with the file system but are entirely in your database (absolutely anything in your database could potentially have been changed). I recommend you check out the info at drupal.stackexchange.com/q/133996/10729 as a good starting point.
    – rooby
    Nov 3, 2014 at 10:45
  • Yes I started there after reading the advisory. Though the trouble with the often quoted flowchart is that for people like me it's saying you're probably hacked and you probably won't see it. Which is, well, a bit confusing when you're trying to work out whether you have a problem or not. I will probably be rebuilding now but I'd still like to understand a bit more on how all of this works.
    – ja_him
    Nov 3, 2014 at 10:55
  • I was thinking more the first 2 posts before the flow chart. Basically if you're really worried and think yo might have been hacked, rebuild your site from a known good revision. Otherwise do as many of those listed checks as possible until you are satisfied that you are safe (only you can decide when you're satisfied). If you still have doubts, then rebuild from a known good revision. If you have no good backups and are still worried then you just have to cross your fingers. Or you could maybe pay a company to do a thorough review, although I don't know if anyone is advertising such services.
    – rooby
    Nov 3, 2014 at 11:04

1 Answer 1

Reset to default
0

You have a couple of questions here so I'll answer the one that I can. File permissions.

The short answer is it depends on your setup as to what the best permissions are.

It depends on your system's users and groups and what account runs the web server process.

There is a lot of more detailed information at Securing file permissions and ownership.

I will give one specific though:

Something to consider aside from the security of your website is the security of your server.

If all your files have to be edited by root does that possibly mean you are regularly using the root account or sudo to do things? If so that is bad for server security. You shouldn't really need to be root to edit website files like that.

Instead of using root maybe use a non-root account with a strong password.

Remember, root is no stronger than any other user in terms of what password they are required to log in with, but has infinitely more power once they're in.

Improve this answer
1
  • Thanks for the edit rooby - yes I have that concern about root myself. Generally we upload developed changes with root and that's it. So from that side of things it's not much of a concern. But I am definitely going to get us away from that practice.
    – ja_him
    Nov 3, 2014 at 10:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.