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) h...@nyu.edu Skype: hfrank71 On Wed, Nov 12, 2014 at 12:26 AM, Cary Gordon <listu...@chillco.com> 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 <h...@nyu.edu> 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) > > h...@nyu.edu > > Skype: hfrank71 > > > > On Sun, Nov 2, 2014 at 1:29 PM, Cary Gordon <listu...@chillco.com> > 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 <andrew.hick...@yale.edu> > >> 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 [CODE4LIB@LISTSERV.ND.EDU <javascript:;>] on > >>> behalf of Lin, Kun [l...@cua.edu <javascript:;>] > >>> Sent: Friday, October 31, 2014 2:10 PM > >>> To: CODE4LIB@LISTSERV.ND.EDU <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:CODE4LIB@LISTSERV.ND.EDU > >> <javascript:;>] > >>> On Behalf Of Cary Gordon > >>> Sent: Friday, October 31, 2014 1:44 PM > >>> To: CODE4LIB@LISTSERV.ND.EDU <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 < > >> onei...@grace.nascom.nasa.gov > >>> <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:CODE4LIB@LISTSERV.ND.EDU > >>> <javascript:;>] On Behalf > >>>>> Of Cary Gordon > >>>>> Sent: Friday, October 31, 2014 11:10 AM > >>>>> To: CODE4LIB@LISTSERV.ND.EDU <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 <l...@cua.edu <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:CODE4LIB@LISTSERV.ND.EDU > >>> <javascript:;> > >>>>>> <javascript:;>] On Behalf Of Cary Gordon > >>>>>> Sent: Friday, October 31, 2014 9:59 AM > >>>>>> To: CODE4LIB@LISTSERV.ND.EDU <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 <deni...@gmail.com > >>> <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 > >> >
