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: Strategist
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.
Veterans Find New Roles in Enterprise Cybersecurity
Kelly Sheridan, Staff Editor, Dark Reading,  11/12/2018
Empathy: The Next Killer App for Cybersecurity?
Shay Colson, CISSP, Senior Manager, CyberClarity360,  11/13/2018
Understanding Evil Twin AP Attacks and How to Prevent Them
Ryan Orsi, Director of Product Management for Wi-Fi at WatchGuard Technologies,  11/14/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Online Malware and Threats: A Profile of Today's Security Posture
Online Malware and Threats: A Profile of Today's Security Posture
This report offers insight on how security professionals plan to invest in cybersecurity, and how they are prioritizing their resources. Find out what your peers have planned today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-15769
PUBLISHED: 2018-11-16
RSA BSAFE Micro Edition Suite versions prior to 4.0.11 (in 4.0.x series) and versions prior to 4.1.6.2 (in 4.1.x series) contain a key management error issue. A malicious TLS server could potentially cause a Denial Of Service (DoS) on TLS clients during the handshake when a very large prime value is...
CVE-2018-18955
PUBLISHED: 2018-11-16
In the Linux kernel 4.15.x through 4.19.x before 4.19.2, map_write() in kernel/user_namespace.c allows privilege escalation because it mishandles nested user namespaces with more than 5 UID or GID ranges. A user who has CAP_SYS_ADMIN in an affected user namespace can bypass access controls on resour...
CVE-2018-19311
PUBLISHED: 2018-11-16
Centreon 3.4.x allows XSS via the Service field to the main.php?p=20201 URI, as demonstrated by the "Monitoring > Status Details > Services" screen.
CVE-2018-19312
PUBLISHED: 2018-11-16
Centreon 3.4.x allows SQL Injection via the searchVM parameter to the main.php?p=20408 URI.
CVE-2018-19318
PUBLISHED: 2018-11-16
SRCMS 3.0.0 allows CSRF via admin.php?m=Admin&c=manager&a=update to change the username and password of the super administrator account.