Software

Drupal SA-CORE-2014-005Drupal Security threats and how we respond at NEWMEDIA!

Here at NEWMEDIA! we are constantly learning and improving. Over the course of the past year we have been refining our continuous integration and hosting platforms as they relate to Drupal. A significant threat, and subsequent fix has been identifeid in all versions of Drupal 7 that has literally rocked the. The good news is that your site is already patched if you are hosting a Drupal 7 site with us. The great news is that we have an opportunity to highlight some of the improvements we have made to our hosting offering.

The new system provides a smoother flow between development efforts and your ability to see the changes. When a developer's code is accepted to your project, it is immediately made visible to you in a password protected staging environment. When the change is approved, it can immediately be made available on the production site. Our systems ensure that the servers developed on are identical to the servers in the staging and production environments. This consistency increases the return on your investment by decreasing the amount of time it takes for a developer to perform their tasks. At the same time, it gaurantees a smoother deployment pipeline.

We are systematically moving all of our hosting properties into this new system.

* Your sites will now be hosted in what is known as Amazon's Virtual Private Cloud. This is the next generation of Amazon's cloud offering that provides advanced network control and separation for increased performance and security.

* Your sites will move from a static ip address to utilize state of the art load balancing techniques. The load balancing and proxy layers provide significant protection agains DDoS and other types of attacks that might be utilized against a website.

* Your DNS management will simplify. The same technology we are using at the load balancing layer allows for a more dynamic system. Because we are moving from addressing the machines by numbers to addressing them by name we are allowed additional flexibility. For example, let's say your site is under a higher than average load. We could temporarily add additional webservers that would increase the performance of your site.

* Site performance will improve. You are being moved to a distributed system that is more capable of handling your sites needs.

The goal of this is to increase the quality of our services and offerings while continuing the tradition of giving back. It is unfortunate that a security issue of this magnitude has affected Drupal. It is good to see the community come together to help bring the current set of continuous integration and deployment practices to the next level.  Come find us at the http://2013.badcamp.net/events/drupal-devops-summit to see how we do continuous.

Help us figure out the best way to share!

Yesterday, when the Drupal 7.31 SQL injection vulnerability came up, I think this was one of the most crititcal updates I ever saw in the Drupal world. First of all - thanks a lot to everybody that helped to find and fix this issue. With the discovering of this security issue and the fix, the Drupal security and the community behind has shown once more how important this combination is. All Drupal sites should and MUST be updated to this version 7.32 to keep their applications secure. An new ERPAL release 2.1 is already available. And it is very important that you use this update for your ERPAL installation.

Why this hurry?

As I already mentioned above, this update is critical to all sites as the vulnerability can be executed by anonymous users. It is possible to get admin access (user 1) with the correct attack sequence. Some of you may ask if Drupal is still secure at all? The answer is still - YES! It is one of the most secure CMF / CMS out there. And with a dedicated security team on Drupal.org many security issues are discovered. Security issues are worst if they are not discovered by the admin / support or security team but only by hackers. And it becomes even worse if people don't update their sites.

So what to do?

Don't panic! You just need to update your site to the latest Drupal 7.32 version. If you are using a distribution, that may have patches included in their installation profile to support all features, check for updates on their project page and get your update there. Easy - Thats it.

How to avoid future problems

Please follow the Drupal security advisories and keep you site's modules up to date. That's one of the most important rules for Drupal users.

While creating business applications with Drupal means for us taking responsibility for all our users to keep their data save and their ERPAL system running. With this blog post I want to ask every Drupal dev, maintainer, client or site builder to update the site immediately.

Faster import & display with Data, Feeds, Views & Panels

Handling loads of data with nodes and fields in Drupal can be a painful experience: every field is put into a separate table which makes inserts and queries slow. In case you just want to import & display unstructured data without the flexibility and sugar of fields, this walkthrough is for you! 

On a recent customer project, we were tasked with importing prices and other information related to products. While we are fine with handling 10k+ products in the database, we didn't want to create field tables for the price information to be attached to products. For every product, we have 10 maybe even more prices which would result in 100k+ prices at least.

The prices shouldn't be involved in anything related to the product search, they should just appear as part of the product view itself. Also there is no commerce system involved at the current state of the project.

Putting the prices into a separate field on the product node may sound like a good idea in the first place. Remember, when loading a list of of those products, all the prices will have to get loaded as well. We wanted those prices to be decoupled from the products, be stored in a lightweight way and only be loaded when necessary - on the single product view.

1) Light-weight data structures in Drupal using the data module

First, I thought implementing a custom entity or just data table would be the way to go. But then we considered giving the data module a try. The data module allows site builders to work on a much lower level than with Drupal fields: you can create database tables, specify their columns and define relationships. What it really makes appealing is that you can access the structured data using views, expose the custom data tables as custom entity types and use the Feeds module for importing that data, without any coding required.

After installing the data module, you can manage your data tables under Structure > Data tables

We create a data table for the product prices and specify the schema with all the columns that should be included. Just like fields but without any fancy formatters on top of it:

This will create the desired database table for you.

Having defined the data, we can use the Entity data module that comes with Data to expose the data table as a custom entity type. By doing so, you will get integrations like for example with Search API for free.

 

2) Import using Feeds and the generic entity processor

Luckily, the [Meta] Generic entity processor issue for the Feeds module has been committed after 3 years of work. As there hasn't been a release since the time of committing the patch (January 2014), this is only available from later dev versions of the Feeds module.

But it's worth the hassle! We can now select from a multitude of different feeds processors based on all the different entity types in the system. After clearing caches, the data tables that we have previously exposed as entity types, do now show up:

The feeds configuration is performed as usual. In the following, we map all the fields from the clients CSV file to the previously defined columns of the data table:

We are now able to import large junks of data without pushing them through the powerful but slow Field API. A test import of ~30k items was performed within seconds. A nodes & Fields based import usually creates 200 items per minute.

3) Data is good, display is better

In the next step, we create a View based on the custom data table to display prices for products. We specify a number of contextual filters so that users will see prices a) the current product and restricted to b) the user's price source and c) currency.

Notice, that the Views display is a (Ctools / Views) Content pane, which has some advanced pane settings in the mid section of the views configuration.

Most importantly, we want to specify the argument input: Usually we would use Context to map the views contextual filters to Ctools contexts that we provide through Panels.

Somehow, in this case, a specific field didn't work with the context system which automatically checks if all necessary context's are available and only allows you to use the Views pane under such circumstances. As you can see in the screenshot above, i have set all arguments to "Input on pane config" as a work around.

Exactly these pane config inputs show up when we configure the Views pane in Panels. In this case, we have added the Product prices view as a pane on the panelized full node display of the Product node type (Drupal jargons ftw!).

Each pane config is populated with the appropriate keyword substitutions based on available contexts node and user of the panelized node.

4) The end result

Finally this is the site builded result of a product node including a prices table:

 

This concludes my how-to on the Data, Feeds, Views and Panels modules to attach a large data sets to nodes without putting them into fields. Once you know how the pieces fit together, it will take you less time than me writing this blog post to import and display large amounts of data in a less flexible, but more performant way! 

I just had the time to watch Larry Garfield's DrupalCon Amsterdam core conversation on managing complexity today. I did not have the chance to attend his session live due to other obligations, but it is nonetheless a topic I am very interested in.

Episode Number: 174

In episode 174, we look at a new way to display administrative messages. In other words, absolute messages is a module that changes how status, error and warning messages are displayed. For the most part, this is a nominal improvement, but does allow for hiding and showing of messages.

Tags: DrupalMessagingDrupal 7Drupal PlanetSite AdministrationUI/Design

Now that Drush has become standard equipment in every developer's toolbox, and Drupal 8 is around the corner, you may find yourself asking "Which Drush version should I use?" While Drush 6 has a stable release, only Drush 7 can be used with Drupal 8. Usually, I use Drush 7. It works well with both Drupal 7 and Drupal 8, and even though is doesn't have a stable release yet, it feels pretty stable to me.

Combining Drush versions: the trouble begins

Unfortunately, when you use Drush 7 to run commands on a remote server which runs Drush 6, you will run into errors. For instance when doing a sql-sync:

$ drush sql-sync @mysite-prod @self You will destroy data in mysite and replace with data from example.com/mysite. Do you really want to continue? (y/n): y Starting to dump database on Source. [ok] Database dump saved to [success] /home/www-data/drush-backups/mysite/20141016113131/mysite_20141016_113132.sql.gz The Drush sql-dump command did not report the path to the dump file produced. Try upgrading the version of Drush you[error] are using on the source machine.

Obviously Drush 7 doesn't like to talk to Drush 6. So how do we solve that?

Installing multiple Drush versions side-by-side

It's not too hard to install two Drush versions side-by-side, and use aliases or symlinks to choose a version. On my system I installed Drush 7 using composer and I installed Drush 6 using the manual method.

Next I created two symlinks called "drush6" and "drush7" in a directory in your $PATH variable. I use ~/bin, but it depends on your OS and configuration.

$ cd ~/bin $ ln -s ~/drush-6.4.0/drush drush6 $ ln -s ~/.composer/vendor/drush/drush/drush drush7

Using those symlinks, I can use both versions anywhere on my system:

$ drush6 --version Drush Version : 6.4.0 $ drush7 --version Drush Version : 7.0-dev

Now I can run drush6 sql-sync @mysite-prod @selfto choose Drush 6 and avoid problems syncing with a remote server.

Automating which version to use

It's nice to be able to choose, but wouldn't it be awesome if you can just run drush ...without having to think which version you need? If you're managing multiple sites on different servers, you don't want to spend your energy remembering which project requires which Drush version.

At Triquanta we use git repositories, one for each project. I want to be able to specify the default Drush version per project, so I will never run the wrong Drush version by mistake. That's where this really simple bash script comes in:

#!/bin/bash version=$(git config --get drush.version) if [ "$version" = '6' ]; then drush6 "$@" else drush7 "$@" fi

Save it as "drush" in a directory in your $PATH variable, and make it executable. Now when you execute drush, it will call this script, which by default runs Drush 7.

$ drush --version Drush Version : 7.0-dev

When a project requires Drush 6 instead, I set a variable "drush.version" in the git working copy:

$ git config drush.version 6 $ drush --version Drush Version : 6.4.0

That's all there is to it. Regardless where you are within your git-managed directory structure (the site root, /sites/default/files/, etc.) the script will always know which drush version to use.

• Drupal 8
• Drush
• Drupal-planet

Published: Fri, 10/17/14Download this episodeThe Drupal Security Team

• What type of people are on the Drupal Security Team?
  • https://security.drupal.org/team-members
  • Mostly coders, some project managers, core maintainers
• What does the security team do?
  • We fix issues in drupal
  • Resolve reported security issues in a Security Advisory
  • Provide assistance for contributed module maintainers in resolving security issues
  • Provide documentation on how to write secure code
  • Provide documentation on securing your site
  • Help the infrastructure team to keep the drupal.org infrastructure secure
• What doesn’t the security team do
  • projects without stable releases
  • Site support
  • Set policy around security with the security working group.
• Is there a D7 security team and a D8 security team with different people? (What about Drupal 6)
• How can others get involved?
• What was the recent bug that was fixed

Questions from Twitter

• Paulius Pazdrazdys
  How this latest security release is different from others? Do you have any information if this bug done any harm before release?
• aboros
  The recent bug was über critical, still only 20/25. What would be a 25/25 bug?
• aboros
  Do you notify any high value targets before SA is sent out? Is the list of those public? Can one be part of this privileged group?
• Carie Fisher
  When the latest bug was found? is there a private drupal security group where this was discussed? could we have found out sooner?
• David Hernandez
  What is the average time from discovery to announcement?
• Damien McKenna
  @ModsUnraveled Are there existing stats on how long it takes from initial reporting, to maintainer response, to first patch & fix?
• Heine Deelstra
  How was SA-CORE-005 (in hindsight) able to be public for so long in the public queue?
• Mark Conroy
  I think the #drupal security team are great. Working extremely hard. (I know, that wasn't a question)
• aboros
  Are there plans for some sort of bounty program run by DA maybe?
• David Hernandez
  What kind of work does the security team do besides review code? What is the administrative overhead?

Episode Links: Greg on drupal.orgGreg on TwitterMichael on drupal.orgMichael on TwitterList of permissions that aren’t includedDrupal Security ReportTwo factor auth moduleParanoia module to prevent php executionSecurity group on g.d.oTags: SecurityDrupal Coreplanet-drupal

It's been 24 hours since Drupal SA-CORE-2014-005 was announced, and we are already beginning to see attacks in the wild. As a platform with 10s of 1000s of Drupal sites, we have a unique perspective on the problem.

This is not a drill: black-hat scripters from sketchy domains are working through lists of known Drupal websites probing for exploits. If you have not patched all your sites, stop reading and do it right now.

...

Ok, now that your websites are safe, here's what we're seeing.

Profiling and Logging Suspected Exploits

We learned of the vulnerability through our participation with the Drupal Security team, so we had a few days to prepare prior to the announcement. At that point, we were under obligation not to share details as part of responsible disclosure, but we did tweet and email customers to "be ready" for the update on Wednesday.

Beyond that, the first step was fashioning our own exploit to have something to build a defense against. I "owned" my personal blog several times getting this right.

With a sense of a potential attack signature, we developed platform-wide request filtering, WAF style. At our scale, we couldn't try to tweak every individual site: a platform solution was the only answer.

We got that deployed on Monday, giving us two days to see the results of real production traffic. We were able to eliminate false-positives while still detecting our PoC attacks, which gave us confidence that our filter would not impact legitimate traffic. That was an important moment, because it meant we could start locking things down.

Log and Block

With the SA announcement on Wednesday we switched the filter from "log" to "log and block". The first detected (and blocked) attack came in at 22:42 UTC (3:42 PM PT), about seven hours after the security announcement. It attempted to set up a fake user with id 9999 and a suspicious temp email address from trbvm.com.

Over the rest of the day we saw a handfull (20-ish) more attacks that looked like proof of concepts or penetration tests. We saw attempts to re-use a proof of concept posted in a Reddit thread, an attempt to create a user named "morpheus" with a pre-set password, and a few attempts to make accounts with the email address test@test.com and then elevate them to an admin role.

It Gets Real

Early this morning at 08:23 UTC (1:23 AM PT) we started seeing an attack that attempts to insert a new item into the menu_router table. This attack is originating from IPs from a VPS provider in the .ru domain space, and it appears to be working through a list of domain names alphabetically.

The attack seems to be the initial part of a multi-step process. The menu_callback it is attempting to create will try to use file_put_contents() to drop a file somewhere in the codebase. That file will pick up a subsequent http request with more of an attack payload in the $_COOKIE superglobal. This sophistication plus the alphabetical attack sequence suggests a professional exploit.

Note that this attack has a 0% chance of success on Pantheon. We block it, but even if we didn't live sites can't write files into the codebase, and a sophisticated $_COOKIE attack would also be stripped. Still, it's concerning.

This Is Not A Drill

It's barely 24 hours after the SA, and we have logged and blocked over 500 attempted attacks on sites on the Pantheon platform. We expect this rate to increase as exploit code is more widely shared and attacks become more automated.

The fact that we are blocking suspect traffic does not mean you delay updating. We're happy to be defending sites on our Platform, but the filter, like CloudFlare's WAF firewall rule is not a guarantee to secure your site. You need to get the update deployed and patch the vulnerability at the source.

If you need help, let us know. If you have friends who need help, lend a hand.

Credits

Credit to the Drupal Security team for organizing a responsible and orderly release. There was likely temptation to rush something out once the severity was realized, but they showed great professionalism by taking a more deliberate route. As soon as the fix was disclosed, black-hats would start working to weaponize the exploit, which we are already seeing.

I'd also like to thank Leonardo Finetti for chiming in based on some tweets with additional information about the menu_router attack. He has his own post up (in Italian) here.

Finally, I'd like to give credit to Greg "greggles" Knaddison for planting the idea in my head of using the reach of our platform as a way to monitor exploit attempts against sites running on Pantheon. Hopefully the data we're able to gather will help everyone defend better and build more secure software and platforms.

Blog Categories: Engineering Tweet

Yesterday, the Drupal Security team announced that all Drupal 7 sites are highly vulnerable to attack. Acquia deployed a platform-wide "shield" which protects all our customer sites, while still keeping them 100% functional for visitors and content editors. These sites can now upgrade to 7.32 in a more calm, controlled timeline.

Apart from presenting a terrific session that will help you wrap your head around developing for Drupal 8, Fredric and I had a great conversation that covered the use of Drupal and open source in government, government decision-making versus corporate decision-making, designing Drupal 7 sites with Drupal 8 in mind, designing sites for the end users and where the maximum business value comes from in your organization, and more!

Topic: DrupalAcquia

You might have read that Acquia was named a leader in the Gartner Magic Quadrant for Web Content Management.

It's easy to underestimate the importance of this recognition for both Acquia and Drupal to be in the leader quadrant. If you want to find a good coffee place, you use Yelp. If you want to find a nice hotel in New York, you use TripAdvisor. Similarly, if a CIO wants to spend $250,000 or more on enterprise software, they consult an analyst firm like Gartner. So think of Gartner as "Yelp for the enterprise".

Many companies create their technology shortlist based on the leader quadrant. That means that Drupal has not been considered as an option for hundreds of evaluations for large projects that have taken place in the past couple of years. Being named a leader alongside companies like Adobe, HP, IBM, Oracle, and Sitecore will encourage more organizations to evaluate Drupal. More organizations evaluating Drupal should benefit the Drupal ecosystem and the development of Drupal.

Last night, Drupal Release a security update to its core - v7.32

 

The release addresses the SQL Injection vulnerability described at https://www.drupal.org/SA-CORE-2014-005

 

 

How serious is it?

There are many proof of concepts scripts available all over the internet now. I have tried a couple of those python scripts and literally anyone who can execute a python script can now login to your Drupal 7 Site as admin, or execute any SQL on your Drupal Database!

[I am not linking them here for the obvious reasons, if you came here searching for those scripts, you are at the wrong place]

 

So, is my site vulnerable?

Most of the Drupal-special webhosts like Acquia, Pantheon, Platform.sh have apparently patched their platforms protecting your Drupal site even if your individual site has not been patched yet. So most of you are safe. You should be worried if you are hosting on one of those generic hosts to whom Drupal is just yet another script or if you are running the site on your own stack.

 

How do I fix my Site?

Don’t worry. Fortunately it is very simple. And it would not take more than 2 minutes to fix your site (if you do it via #3 below).

 

If the words like “git”, “patch”, “upgrade” scare you and if you like the words “FTP”, “Filezilla” more then skip directly to #3 below.

 

• OPTION #1: The first option is to update your site to the latest version of Drupal - 7.32.

• OPTION #2:But yeah, there is considerable effort involved behind upgrading your Drupal Site. Every upgrade usually would require significant regression testing and this could take a while.
  
  So, as an alternative, there is a very small patch out there for  you. Apply it and you are all set.
  Patch : https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch
  
  How do I apply this patch?
  Like any other patch -

  • SSH To your drupal root directory

  • Get the patch by executing the command
    wget http://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch

  • Assuming you got git on the server, run the command
    git apply -v SA-CORE-2014-005-D7.patch
    
    If you see something like this, you are all set now :-)
    
     

• OPTION #3: [THE SIMPLEST OF ALL] Alternatively, if you do not want to deal with patches or upgrades, or if you are are looking for a quick fix, here you go:

  • FTP to, or open your Drupal Root Directory

  • Navigate to  includes/database/ folder

  • There will be a file named database.inc . Take a backup of the file. We are going to modify the file. Store the backup somewhere safe just in case.

  • Open the file database.inc .

  • At around line 739, you will find a line of code that reads
    foreach ($data as $i => $value) {
    Replace this line with
    foreach (array_values($data) as $i => $value) {

  • Save the file and exit

  • Pat yourself on the back. You are all set now :-)

 

I have no enemies. Should I still fix my site?

Absolutely yes. With the many google dorks that could be used to find Drupal Sites, you could be the subject of random attack. - ie Some noob with the script picking up your site randomly to login as admin and defacing it or playing around with it, or stealing your userbase for spamming!

 

Who found this issue? Who reported it? When was it first reported? ……. Check out the FAQ on Drupal.org for answers - https://www.drupal.org/node/2357241

 

Too often clients add autocomplete as an requirement without much thought. And as an result it is actually making the user experience worse. Instead of helping the users it confuses them. The first rule when designing autocomplete is: the suggestions must be relevant for many! Otherwise don’t make any suggestions at all, since it’s just […]

We're accustomed to the Drupal security team releasing security fixes.

Fortunately, most of the fixes were relatively minor. They either impacted a small group of sites, or they were unlikely to lead to your site being hacked.

Let's take a brief look at the 4 previous Drupal security advisories in 2014:

How can the Drupal community recognise and handle conflict more constructively? This core conversation session from DrupalCon Amsterdam aimed to start a discussion about creating an army of empowered bystanders ready, willing and able to use conflict as a positive force in the community.

How can the Drupal community recognise and handle conflict more constructively? This core conversation session from DrupalCon Amsterdam aimed to start a discussion about creating an army of empowered bystanders ready, willing and able to use conflict as a positive force in the community.

Earlier today, the Drupal Security Team announced SA-CORE-2014-005 - Drupal core - SQL injection, a 'Highly Critical' bug in Drupal 7 core that could result in SQL injection, leading to a whole host of other problems.

While not a regular occurrence, this kind of vulnerability is disclosed from time to time—if not in Drupal core, in some popular contributed module, or in some package you have running on your Internet-connected servers. What's the best way to update your entire infrastructure (all your sites and servers) against a vulnerability like this, and fast? High profile sites could be quickly targeted by criminals, and need to be able to deploy a fix ASAP... and though lower-profile sites may not be immediately targeted, you can bet there will eventually be a malicious bot scanning for vulnerable sites, so these sites need to still apply the fix in a timely manner.

Today a highly critical security update (SA-CORE-2014-005) was released for Drupal 7. Any Drupal site running Drupal 7.31 or lower needs to update to 7.32 or apply the patch immediately. Here are some tips to get your Drupal 7 site updated today!

Marketers around the world face the same pressures of trying to leverage marketing automation, content marketing, social media engagement, SEO, and more to drive prospective buyers to engage with their brands.

Last time we explored some different options that determined how the login form was displayed on your site. Today we're going to expand on that and look at different ways of wrangling or changing the actual login experience for your users. The default settings aren't exactly very refined and so it can take some configuration to get a better user experience out of the whole process.

read more