Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

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
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
BradleyRoss
50%
50%
BradleyRoss,
User Rank: Moderator
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.
7 Tips for Choosing Security Metrics That Matter
Ericka Chickowski, Contributing Writer,  10/19/2020
IoT Vulnerability Disclosure Platform Launched
Dark Reading Staff 10/19/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15270
PUBLISHED: 2020-10-22
Parse Server (npm package parse-server) broadcasts events to all clients without checking if the session token is valid. This allows clients with expired sessions to still receive subscription objects. It is not possible to create subscription objects with invalid session tokens. The issue is not pa...
CVE-2018-21266
PUBLISHED: 2020-10-22
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Notes: none.
CVE-2018-21267
PUBLISHED: 2020-10-22
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Notes: none.
CVE-2020-27673
PUBLISHED: 2020-10-22
An issue was discovered in the Linux kernel through 5.9.1, as used with Xen through 4.14.x. Guest OS users can cause a denial of service (host OS hang) via a high rate of events to dom0, aka CID-e99502f76271.
CVE-2020-27674
PUBLISHED: 2020-10-22
An issue was discovered in Xen through 4.14.x allowing x86 PV guest OS users to gain guest OS privileges by modifying kernel memory contents, because invalidation of TLB entries is mishandled during use of an INVLPG-like attack technique.