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: 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.
Crowdsourced vs. Traditional Pen Testing
Alex Haynes, Chief Information Security Officer, CDL,  3/19/2019
BEC Scammer Pleads Guilty
Dark Reading Staff 3/20/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Well, at least it isn't Mobby Dick!
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
The State of Cyber Security Incident Response
The State of Cyber Security Incident Response
Organizations are responding to new threats with new processes for detecting and mitigating them. Here's a look at how the discipline of incident response is evolving.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-20165
PUBLISHED: 2019-03-22
Cross-site scripting (XSS) vulnerability in OpenText Portal 7.4.4 allows remote attackers to inject arbitrary web script or HTML via the vgnextoid parameter to a menuitem URI.
CVE-2019-1716
PUBLISHED: 2019-03-22
A vulnerability in the web-based management interface of Session Initiation Protocol (SIP) Software for Cisco IP Phone 7800 Series and Cisco IP Phone 8800 Series could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition or execute arbitrary code. The vulnerability ...
CVE-2019-1763
PUBLISHED: 2019-03-22
A vulnerability in the web-based management interface of Session Initiation Protocol (SIP) Software for Cisco IP Phone 8800 Series could allow an unauthenticated, remote attacker to bypass authorization, access critical services, and cause a denial of service (DoS) condition. The vulnerability exist...
CVE-2019-1764
PUBLISHED: 2019-03-22
A vulnerability in the web-based management interface of Session Initiation Protocol (SIP) Software for Cisco IP Phone 8800 Series could allow an unauthenticated, remote attacker to conduct a cross-site request forgery (CSRF) attack. The vulnerability is due to insufficient CSRF protections for the ...
CVE-2019-1765
PUBLISHED: 2019-03-22
A vulnerability in the web-based management interface of Session Initiation Protocol (SIP) Software for Cisco IP Phone 8800 Series could allow an authenticated, remote attacker to write arbitrary files to the filesystem. The vulnerability is due to insufficient input validation and file-level permis...