Hi Cary,
Thank you for responding! I've had some direct contacts, so hopefully will
get it resolved.
thanks for everyone's willingness to help!
best,
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 Wed, Nov 12, 2014 at 12:26 AM, Cary Gordon <[log in to unmask]> wrote:
> If the site was not patched within a few hours of the announcement, the
> odds are that you will need to rebuild it from a backup made before October
> 15th. It is very difficult to detect a successful exploit, or predict if a
> back-door will be used.
>
> I suggest that your first move should be to contact Bluehost, as they may
> have done the patch for you. If not, please read the rest of this thread.
> If you have more questions or need help, let us know here. I will attempt
> to address any issue that is explored in this forum.
>
> Cary
>
>
> > On Nov 11, 2014, at 8: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
> >>
>
|
