“You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched…”
Alas, yes. See also https://www.drupal.org/node/2357241
If you didn’t upgrade within 7 hours of the update on the 15th of October, it’s fun times.
Did you read this link?
They did a nice job of explaining…
Indeed this will be a messy one.
Does Dreamhost moderate these forums and help guys - or is this a users-only forum? What I curious about with this issue (public service announcement: https://www.drupal.org/PSA-2014-003) is if we ideally need to close down VPS instances and create new ones?
I.E. Drupal security team’s advice is to “Consider obtaining a new server, or otherwise remove all the website’s files and database from the server” and so the question is whether a Dreamhost VPS is entirely isolated from this threat and/or should we delete the old VPS while creating new VPS instances and follow the rest of the advice (from https://www.drupal.org/PSA-2014-003).
I’ll send note to Dreamhost support directly anyway with a link here and will follow-up with any advice/explanation offered - although if anyone understand Dreamhost VPS/physical server architecture in connection with this particular SQL injection type attack then it would be great to get a direct reply here too.
Each VPS is isolated from this threat, so if Bob’s Drupal site is infected, only his site and others on his account run the risk of infecting each other.
Also we DID block the SQL injection attacks if you kept Extra Web Security on for your site. See? It’s a good thing
So when Drupal says “or otherwise remove all the website’s files and database from the server” they literally mean if you delete ALL the files from your server, take the DB down, and then upload it all from clean and fresh downloads from Drupal.com, you should be okay.
Of course that won’t clean your uploads, which have to be checked manually, nor your database (ditto). I’m not a Drupal expert, but I know the theory is the same as with a hacked WP site. Clear out the files, only upload ones you KNOW are good, and if possible check the database. I read through https://www.drupal.org/node/2365547 and with the exception of that DB, I think it’s pretty much the same as WP.
@ipstenu-DH That’s a great reply and good news - about the VPS isolation as I didn’t know that. One thing I’m not so sure about is if the sites are ‘immune’ from this particular vulnerability if we did, as in fact we have, kept ‘Extra Web Security’ turned on?
I’ll post this reply, if you don’t mind, on the main Drupal FAQ for this issue: https://www.drupal.org/drupalsa05FAQ to see if they agree. If so, it should be good for business for Dreamhost as many other sites/Drupal developers seems to have caught a pretty big cold with the issue.
No, not immune. As soon as we know about it, we DID add the SQL injection protection, but of course, we didn’t know about it for those crucial 7+ hours either. Just saying that once we knew, like everyone else, we did our best to mitigate it as much as humanly possible from our end and protect our users. Didn’t do a thing if you were already infected though
FWIW, pretty much every host would have done this, but you’re welcome to tell Drupal that DreamHost did add in a mod_security check for those sql injections as fast as we could.
(One of my least favorite hacks is anything injected into the DB, it makes me wanna drink)
Thanks for clarify that @ipstenu-DH.
thanks again @ipstenu-DH. The other aspect about this that might help others too is the mysql vps arrangement and how (or if) the mysql databases are also isolated from each and without danger of similar intrusions (if, for example, another mysql on the mysql vps had been comprised)?
I.E. by default it seems we can only have a single VPS MySQL server per account (“Currently, one is the maximum per DreamHost account”) and I’m planning on dropping each old db and creating clean new db instances on the current VPS (the only one we are allowed). Is that best practice/safe in this scenario?
Thanks again for any help/advice.
MySQL databases are sufficiently isolated from each other that you don’t need a new database server; just creating a new MySQL database, on a new user, is sufficient.
While it’s possible to create MySQL users through the DreamHost Panel that have access to multiple databases, that’s not the default, and it doesn’t apply retroactively: an existing MySQL user will never have access to a newly created database unless you explicitly go into the panel and give them access.
Many thanks Andrew F. That’s great to know and much appreciated.
Thank you. This clears out my doubt but I have never seen something that clarifies this until now.