 |
 |
I have a bluehost site with Wordpress on it. In my case whenever a vulnerability has been discovered they have been very good about automatically updating it. Keep in mind this is a standard instal using cpanel. Your mileage may vary if you did something custom. Edward Iglesias On Tue, Nov 11, 2014 at 11:40 PM, Heidi P Frank <[log in to unmask]> wrote: > Hi, > A colleague and I volunteer for an organization to maintain their website, > which is a Drupal site hosted on Bluehost, however, neither of us are very > experienced with Drupal. So we've been trying to figure out what we need > to do to prevent the site from being affected by this vulnerability issue, > and have read a lot of the documentation and tried following the > instructions to upgrade, etc. but are still having trouble. > > If there is anyone on this list who would be willing to speak with us and > answer some questions about how we need to proceed, please contact me off > list. Any guidance will be much appreciated with numerous Thank You's! > (i.e., we need some pro bono assistance :) > > cheers, > Heidi > > Heidi Frank > Electronic Resources & Special Formats Cataloger > New York University Libraries > Knowledge Access & Resources Management Services > 20 Cooper Square, 3rd Floor > New York, NY 10003 > 212-998-2499 (office) > 212-995-4366 (fax) > [log in to unmask] > Skype: hfrank71 > > On Sun, Nov 2, 2014 at 1:29 PM, Cary Gordon <[log in to unmask]> wrote: > > > If you can migrate to a maintained service, you could use feeds or > migrate > > to move your content. You could also take that approach on your own > > new site. Obviously, none of your entities — nodes, menus, users, blocks, > > taxonomies, etc. — should contain executable code. > > > > I suggest that you do not migrate users or menus, unless you have the > > ability to validate your data. > > > > I love the internets, but I have learned that nobody should be > > running public facing services — open-source or other — unless they are > > prepared to maintain them, including managing a disaster recovery plan > and > > vigilantly monitoring and acting on security notices. If this is not > > doable, use a service provider to manage it. The days of running services > > from a computer under a desk are gone. > > > > Cary > > > > On Sunday, November 2, 2014, Hickner, Andrew <[log in to unmask]> > > wrote: > > > > > I'd be curious to hear how others are proceeding. We had already > planned > > > to migrate our D7 sites to a centralized Drupal instance offered here > at > > > Yale and this has just accelerated the timetable. I imagine there are > a > > > lot of libraries running Drupal though who don't have this kind of > option > > > and might not have pre-October 15 backups to revert to (we don't!) > > > > > > > > > > > > Andy Hickner > > > Web Services Librarian > > > Yale University > > > Cushing/Whitney Medical Library > > > http://library.medicine.yale.edu/ > > > > > > ________________________________________ > > > From: Code for Libraries [[log in to unmask] <javascript:;>] on > > > behalf of Lin, Kun [[log in to unmask] <javascript:;>] > > > Sent: Friday, October 31, 2014 2:10 PM > > > To: [log in to unmask] <javascript:;> > > > Subject: Re: [CODE4LIB] Terrible Drupal vulnerability > > > > > > I think so. However, Cloudflare in their blog post claim they have > > develop > > > a way to block the attack immediately when the vulnerability was > > announced. > > > Whether or not they know the exploit ahead of time or not, it would be > > good > > > to know someone is watching out for you for $20 a month. And you will > be > > > mad if you took Oct 15th off without it. I just check, I patched my > > > instance on Oct 16th. Not sure what's going to happened. > > > > > > Kun > > > > > > -----Original Message----- > > > From: Code for Libraries [mailto:[log in to unmask] > > <javascript:;>] > > > On Behalf Of Cary Gordon > > > Sent: Friday, October 31, 2014 1:44 PM > > > To: [log in to unmask] <javascript:;> > > > Subject: Re: [CODE4LIB] Terrible Drupal vulnerability > > > > > > The vulnerability was discovered in the course of an audit by > > SektionEins, > > > a German security firm, and immediately reported to the Drupal Security > > > Team. Because this was a pretty obscure vulnerability with no reported > > > exploits, the team decided to wait until the first scheduled release > date > > > after DrupalCon Amsterdam to put out the notice and patch. Obviously, > > they > > > knew that once word of the vulnerability was announced, there would > > > immediately be a wave of exploits, so they imposed a blackout on any > > > mention of it before October 15th. I think that they stuck to their > word. > > > > > > Of course, attacks started a few hours after the announcement. > > > > > > Cary > > > > > > > On Oct 31, 2014, at 9:38 AM, Joe Hourcle < > > [log in to unmask] > > > <javascript:;>> wrote: > > > > > > > > On Oct 31, 2014, at 11:46 AM, Lin, Kun wrote: > > > > > > > >> Hi Cary, > > > >> > > > >> I don't know from whom. But for the heartbeat vulnerability earlier > > > this year, they as well as some other big providers like Google and > > Amazon > > > were notified and patched before it was announced. > > > > > > > > If they have an employee who contributes to the project, it's > possible > > > > that this was discussed on development lists before it was sent down > > > > to user level mailing lists. > > > > > > > > Odds are, there's also some network of people who are willing to > give > > > > things a cursory review / beta test in a more controlled manner > before > > > > they're officially released (and might break thousands of websites). > > > > It would make sense that companies who derive a good deal of their > > > > profits in supporting software would participate in those programs, > as > > > well. > > > > > > > > I could see categorizing either of those as 'ahead of the *general* > > > > public', which was Kun's assertion. > > > > > > > > -Joe > > > > > > > > > > > > > > > >> -----Original Message----- > > > >> From: Code for Libraries [mailto:[log in to unmask] > > > <javascript:;>] On Behalf > > > >> Of Cary Gordon > > > >> Sent: Friday, October 31, 2014 11:10 AM > > > >> To: [log in to unmask] <javascript:;> > > > >> Subject: Re: [CODE4LIB] Terrible Drupal vulnerability > > > >> > > > >> How do they receive vulnerability report ahead of general public? > From > > > whom? > > > >> > > > >> Cary > > > >> > > > >> On Friday, October 31, 2014, Lin, Kun <[log in to unmask] <javascript:;>> > > > wrote: > > > >> > > > >>> If you are using drupal as main website, consider using Cloudflare > > Pro. > > > >>> It's just $20 a month and worth it. They'll help block most > attacks. > > > >>> And they usually receive vulnerability report ahead of general > > public. > > > >>> > > > >>> Kun > > > >>> > > > >>> -----Original Message----- > > > >>> From: Code for Libraries [mailto:[log in to unmask] > > > <javascript:;> > > > >>> <javascript:;>] On Behalf Of Cary Gordon > > > >>> Sent: Friday, October 31, 2014 9:59 AM > > > >>> To: [log in to unmask] <javascript:;> <javascript:;> > > > >>> Subject: Re: [CODE4LIB] Terrible Drupal vulnerability > > > >>> > > > >>> This is what I posted to the Drupal4Lib list: > > > >>> > > > >>> -------------------- > > > >>> > > > >>> By now, you should have seen https://www.drupal.org/PSA-2014-003 > and > > > >>> heard about the "Drupageddon" exploits. and you may be wondering if > > > >>> you were vulnerable or iff you were hit by this, how you can tell > > > >>> and what you should do. Drupageddon affects Drupal 7, Drupal 8 and, > > > >>> if you use the DBTNG module, Drupal 6. > > > >>> > > > >>> The general recommendation is that if you do not know or are unsure > > > >>> of your server's security and you did not either update to Drupal > > > >>> 7.32 or apply the patch within a few hours of the notice, you > should > > > >>> assume that your site (and server) was hacked and you should > restore > > > >>> everything to a backup from before October 15th or earlier. If your > > > >>> manage your server and you have any doubts about your file > security, > > > >>> you should restore that to a pre 10/15 image, as well or do a > > > reinstall of your server software. > > > >>> > > > >>> I know this sounds drastic, and I know that not everyone will do > > that. > > > >>> There are some tests you can run on your server, but they can only > > > >>> verify the hacks that have been identified. > > > >>> > > > >>> At MPOW, we enforce file security on our production servers. Our > > > >>> deployments are scripted in our continuous integration system, and > > > >>> only that system can write files outside of the temporal file > > > directory (e.g. > > > >>> /sites/site-name/files). We also forbid executables in the temporal > > > >>> file system. This prevents many exploits related to this issue. > > > >>> > > > >>> Of course, the attack itself is on the database, so even if the > file > > > >>> system is not compromised, the attacker could, for example, get > > > >>> admin access to the site by creating an account, making it an > admin, > > > >>> and sending themselves a password. While they need a valid email > > > >>> address to set the password, they would likely change that as soon > as > > > they were in. > > > >>> > > > >>> Some resources: > > > >>> https://www.drupal.org/PSA-2014-003 > > > >>> > > > >>> > https://www.acquia.com/blog/learning-hackers-week-after-drupal-sql-i > > > >>> nj > > > >>> ection-announcement > > > >>> > > > >>> > http://drupal.stackexchange.com/questions/133996/drupal-sa-core-2014 > > > >>> -0 05-how-to-tell-if-my-server-sites-were-compromised > > > >>> > > > >>> I won't attempt to outline every audit technique here, but if you > > > >>> have any questions, please ask them. > > > >>> > > > >>> The takeaway from this incident, is that while Drupal has a great > > > >>> security team and community, it is incumbent upon site owners and > > > >>> admins to pay attention. Most Drupal security issues are only > > > >>> exploitable by privileged users, and admins need to be careful and > > > >>> read every security notice. If a vulnerability is publicly > > > exploitable, you must take action immediately. > > > >>> > > > >>> Thanks, > > > >>> > > > >>> Cary > > > >>> > > > >>> On Thu, Oct 30, 2014 at 5:24 PM, Dan Scott <[log in to unmask] > > > <javascript:;> > > > >>> <javascript:;>> wrote: > > > >>> > > > >>>> Via lwn.net, I came across https://www.drupal.org/PSA-2014-003 > and > > > >>>> my heart > > > >>>> sank: > > > >>>> > > > >>>> """ > > > >>>> Automated attacks began compromising Drupal 7 websites that were > > > >>>> not patched or updated to Drupal 7.32 within hours of the > > > >>>> announcement of > > > >>>> SA-CORE-2014-005 > > > >>>> - <https://www.drupal.org/SA-CORE-2014-005>Drupal > > > >>>> <https://www.drupal.org/SA-CORE-2014-005> core - SQL injection > > > >>>> <https://www.drupal.org/SA-CORE-2014-005>. You should proceed > under > > > >>>> the assumption that every Drupal 7 website was compromised unless > > > >>>> updated or patched before Oct 15th, 11pm UTC, that is 7 hours > after > > > >>>> the > > > >>> announcement. > > > >>>> """ > > > >>>> > > > >>>> That's about as bad as it gets, folks. > > > >>>> > > > >>> > > > >>> > > > >>> > > > >>> -- > > > >>> Cary Gordon > > > >>> The Cherry Hill Company > > > >>> http://chillco.com > > > >>> > > > >> > > > >> > > > >> -- > > > >> Cary Gordon > > > >> The Cherry Hill Company > > > >> http://chillco.com > > > > > > > > > -- > > Cary Gordon > > The Cherry Hill Company > > http://chillco.com > > >