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
> >
>