 |
 |
http://blog.ircmaxell.com/2014/10/a-lesson-in-security.html is an interesting and thoughtful write-up on the technical details of this vulnerability. On Fri, Oct 31, 2014 at 12:38 PM, Joe Hourcle <[log in to unmask] > 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]] On Behalf Of > Cary Gordon > > Sent: Friday, October 31, 2014 11:10 AM > > To: [log in to unmask] > > 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]> 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:;>] On Behalf Of Cary Gordon > >> Sent: Friday, October 31, 2014 9:59 AM > >> To: [log in to unmask] <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-inj > >> 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:;>> 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 >