Attacks/Breaches

4/30/2018
07:30 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

Speed at Which New Drupal Flaw Was Exploited Highlights Patching Challenges

In the rush to patch, organizations can create fresh problems for themselves.

The speed at which malicious attackers recently exploited a remote code execution flaw in the Drupal content management system (CMS) should serve as fresh warning about the need for organizations to test processes for quickly responding to vulnerability disclosures.

Drupal administrators last Wednesday rushed out an out-of-cycle security release warning about a highly critical vulnerability (CVE-2018-7602) affecting Drupal 7.x and 8.x versions. The new vulnerability — related to an even more severe and somewhat incompletely fixed flaw (CVE-2018-7600) from March — potentially gives threat actors multiple ways to attack a Drupal site, maintainers of the open source CMS platform warned.

They urged website owners and operators to immediately update to the most recent version of Drupal 7 or Drupal 8 core. Sites running 7.x were asked to upgrade to Drupal 7.59; those using 8.5.x to Drupal 8.5.3; and those on Drupal 8.4.x to Drupal 8.4.8. For organizations unable to update quickly enough, the Drupal administrators issued a security patch to mitigate the risk of the vulnerability being exploited.

But barely hours after the advisory was posted, attackers began actively exploiting the flaw to try, among other things, to upload cryptocurrency miners on vulnerable sites or to use compromised sites to launch distributed denial-of-service attacks. In virtually no time at all — and certainly before a vast majority of site owners had an opportunity to upgrade or apply mitigations — thousands of host systems around the world became potential targets for compromise.

The speed at which attackers attempted to take advantage of the newly disclosed Drupal flaw was in stark contrast to March, when it took about two weeks for the first attacks against CVE-2018-7600 to surface. Hacker activity around March's so-called Drupalgeddon 2.0 was so low initially that it prompted security vendor Imperva to wonder if hackers were getting lazy.

"Unlike CVE-2018-7600, which took two weeks to exploit, CVE-2018-7602 was exploited within 24 hours," says Koby Kilimnik, security researcher at Imperva. In fact, a public exploit was publicly published for CVE-2018-7602 just a few hours after the vulnerability was disclosed, he says.

"The ongoing vulnerabilities announced around Drupal and the speed through which proof-of-concept exploit code was developed only further highlights the importance and need of organizations to understand their attack surface," says Steve Ginty, senior product manager at RiskIQ.

Responding to such threats requires organizations to be able to quickly identify vulnerable assets — including those that are likely being managed by third parties — in order to secure them appropriately. "While organizations may not be able to patch these vulnerable platforms, visibility into the scope of the impact on an enterprise allows an organization to make an informed risk decision," Ginty says.

The trend toward faster exploitation of vulnerabilities puts enterprises between a rock and a hard place. Faulty patches and badly implemented ones can create as much or even greater problems than the security issues they are meant to address. Many enterprises prefer to thoroughly test patches before putting them into production environments — a process that can take anywhere from a couple of days to several months, depending on size. While that might be a safe approach, delaying patch deployment can expose organizations to considerable risk as well, as last week's Drupal flaw showed.

"The challenge of maintaining security patches while preventing disruption of production systems is a huge problem for IT professionals," says Justin Jett, director of audit and compliance for Plixer. Many security patches — including those for commonly used software like Drupal — do not alter the core functionality of the software and so can be deployed without too much risk.

"While major software releases can typically wait until thorough testing has been completed, minor security-related patches should be completed as soon as possible, if not immediately after the patch is made publicly available," Jett says.

At the same time, past experience has shown that relying entirely on vendor patches is not always the best idea, says Imperva's Kilimnik. "Vendors might be in a hurry to publish a patch without proper tests, so it could have a dangerous effect in your environment," he says. "We cannot always predict how patching one system might affect the other," so other mitigations might become necessary, he adds.

Related Content:

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
BradleyRoss
50%
50%
BradleyRoss,
User Rank: Apprentice
5/2/2018 | 10:58:51 AM
I'm surprised it wasn't quicker
The code for the patch is the difference between versions 8.4.7 and 8.4.8 and between 8.5.2 and 8.5.3.  If you go to the GitHub page and click on the link for the releases ("314 releases"), you will get a list of all of the releases and you can download the complete source for the releases mentioned above.  Getting a list of the differences between the versions can be done with any of a number of software development tools.

Since this vulnerability is apparently very similar to a previous vulnerability that was partially fixed, combining the information from the previous vulnerability with the differences in the code will practically provide step-by-step instructions for exploiting the new vulnerability.

Given this, I don't find it at all surprising that exploits were seen in the wild within a day of the patch being released.  Depending on how the GitHub repository is organized, I would expect exploits to start appearing a day before the patch.  Remember that the attackers don't have to do rigorous testing.
RyanSepe
100%
0%
RyanSepe,
User Rank: Ninja
4/30/2018 | 11:01:54 PM
Barely hours after....
"Patching challenges" In a situation such as this, even patching out of band cannot remediate the exposure quick enough. In this vein, we would need to rely on compensating controls to help shelter the blow.
White House Cybersecurity Strategy at a Crossroads
Kelly Jackson Higgins, Executive Editor at Dark Reading,  7/17/2018
Lessons from My Strange Journey into InfoSec
Lysa Myers, Security Researcher, ESET,  7/12/2018
What's Cooking With Caleb Sima
Kelly Jackson Higgins, Executive Editor at Dark Reading,  7/12/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2016-9574
PUBLISHED: 2018-07-19
nss before version 3.30 is vulnerable to a remote denial of service during the session handshake when using SessionTicket extension and ECDHE-ECDSA.
CVE-2017-2673
PUBLISHED: 2018-07-19
An authorization-check flaw was discovered in federation configurations of the OpenStack Identity service (keystone). An authenticated federated user could request permissions to a project and unintentionally be granted all related roles including administrative roles.
CVE-2017-7481
PUBLISHED: 2018-07-19
Ansible before versions 2.3.1.0 and 2.4.0.0 fails to properly mark lookup-plugin results as unsafe. If an attacker could control the results of lookup() calls, they could inject Unicode strings to be parsed by the jinja2 templating system, resulting in code execution. By default, the jinja2 templati...
CVE-2018-12911
PUBLISHED: 2018-07-19
WebKitGTK+ 2.20.3 has an off-by-one error, with a resultant out-of-bounds write, in the get_simple_globs functions in ThirdParty/xdgmime/src/xdgmimecache.c and ThirdParty/xdgmime/src/xdgmimeglob.c.
CVE-2018-14404
PUBLISHED: 2018-07-19
A NULL pointer dereference vulnerability exists in the xpath.c:xmlXPathCompOpEval() function of libxml2 through 2.9.8 when parsing an invalid XPath expression in the XPATH_OP_AND or XPATH_OP_OR case. Applications processing untrusted XSL format inputs with the use of the libxml2 library may be vulne...