Security Vulnerabilities Affect Your Dev Sites Too | mydropwizard.com

When Drupalgeddon 2 (SA-CORE-2018-002) happened a few weeks back, we saw plenty of buzz from agencies and other organizations throughout the community who were having patching parties.

Yay for patching! But were you left vulnerable by not updating all of your installations?

If you didn’t update development and staging sites, you may be at risk!

Due to the nature of the vulnerability, from the largest of enterprise applications to the smallest of brochure or hobbyist site builds, all Drupal sites were affected. This includes any testing or staging versions of your site. Depending on how you manage your local development sites, even those may have been exposed too!

Still not convinced? Read more to find out why you need to update ALL sites!

It's Just the Dev Site, What Could Go Wrong?

Far too commonly developers write off development environments as temporary or non-essential, unconcerned about the implications of those sites getting hacked. Typically those can be thrown away or easily rebuilt, but the functionality of the site itself is only one aspect of the vulnerability.

Where does the data on your staging environment come from?

In many cases production data gets copied into your staging and development sites for testing. In fact, Acquia and Pantheon give you simple tools to perform this very function. Some types of security vulnerabilities could allow an attacker to gain access to some or all of the data including users/profiles, e-commerce transactions, and other restricted content.

An exposed site leaves a target area at an infrastructure level, too.

A vulnerability that lets an attacker access the server or run unauthorized code (remote code execution, for instance) jeopardizes the entire server. Hackers may use the exploit for unsavory or nefarious purposes, such as dispatching spam email or Bitcoin mining (link is external).

Even worse, if you’ve got development or staging sites colocated on the production server, an attacker could use the vulnerability in your development site to access your production site.

This could let an attacker access or change live, potentially-sensitive, production data. This scenario also exposes any other infrastructure your site uses, including accessing 3rd-party services.

Mitigate Those Other Sites

At myDropWizard we use a two-pronged approach to dealing with potentially insecure non-production environments:

The first, and easiest, solution is to decommission any environments that aren’t needed.

This is something that should be done as part of routine upkeep, not necessarily due to a security scare, but in a pinch just power down those non-essential servers or otherwise take the sites offline.

The second option, which applies to production or otherwise essential environments, is to address the security vulnerability.

Generally this means updating affected project to the release the release which includes the fix but this isn’t the only option. For sites where upgrading to the next release may be problematic or risky, patching just the vulnerability may be the best way to address the security risk while avoiding unnecessary changes.

Conclusion

In short: Your exposure to security vulnerabilities is more that just your production site.

Every additional instance of a site widens its attack surface. Be sure to keep all of your environments up to date, as your development and staging sites can expose you to just as serious of an attack as the production site.

During Drupalgeddon 2, myDropWizard performed this work on behalf of our customers as they continued on with business as usual. Within just a few hours of the security advisory being published, we not only had all customer productions sites been updated or patched, but all other environments that myDropWizard was tasked with were also upgraded, patched, or spun down.

Our agency clients got to keep on pushing ahead with their active development, while our other clients got to keep working to achieve their objectives--whatever they may be.