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.

Vulnerabilities / Threats

9/11/2017
09:00 AM
Matthew Gardiner
Matthew Gardiner
Sponsored Article
Connect Directly
Twitter
RSS
E-Mail
50%
50%

'ROPEMAKER:' Behind the Scenes of an Exploit Disclosure

How 'social responsibility' and 'false security' played into the unmasking of a recently disclosed email vulnerability.

Threat research reminds me of a well-known saying describing the experience of an army at war: "boredom punctuated by moments of terror." That's a bit of hyperbole, for sure, when related to IT security. Threat research is rarely boring, but most of the time it isn’t incredibly exciting either. It is generally focused on the day-to-day grinding out of incremental discoveries to keep security defenses current.

I also don’t think in the everyday world of threat research we often reach the level of "terror," thankfully!  But threat research can get heated and be exciting at times, particularly when preparing to publish a significant discovery of a new vulnerability or exploit.

Recently the threat research team at Mimecast disclosed an email exploit named ROPEMAKER.  After the initial testing work to discover and confirm ROPEMAKER'S multiple exploit techniques (which took months), Mimecast went through the rigorous and lengthy process generally referred to as responsible disclosure. I will let you read the entire Wikipedia entry defining responsible disclosure, but two of the key terms in this definition that hit home for me are: social responsibility and false security

There are multiple conundrums associated with publicly disclosing new exploits or application vulnerabilities. Not the least of which are:

  • Who should you tell?
  • When should you tell them?
  • How do you tell them?
  • How do you know if you have told the right people?
  • How do you take competitive pressures out of the picture?
  • What do you do if you don’t get the hoped-for responses?
  • When should you go public with your discovery?

In the case of ROPEMAKER the disclosure process was made particularly difficult because it isn’t clear if the exploit takes advantage of an email application vulnerability, the abuse or misuse of an otherwise properly working application (HTML-based email), or if it is a systemic design flaw in associated Internet standards that provides an exploitable system to malicious actors. It also could be a bit of all three. 

Of course, an exploit that doesn’t clearly fall into one area leaves open the possibility that no one takes ownership of the issue or even recognizes it as an issue. I firmly believe it is part of Mimecast’s social responsibility to disclose it anyway, after going through a reasonable responsible disclosure process, because a lack of disclosure won’t make the security issue go away. Also, more eyes on the issue can lead to a better resolution.

What I'm leading to is the ultimate conundrum of public exploit and vulnerability disclosure: what if the attackers, as they often do, move faster than the defenders, and start taking advantage of newly disclosed research for their malicious purposes?  We know this is possible, even likely.  One must look no further than recent exploits, such as Wannacry, in which attackers took advantage of known vulnerabilities that had patches available for months, but that were not applied in time by many organizations. This led to a widespread spate of ransomware infections.

This is where the issue of false security comes to play. People and organizations are not safer when they lack knowledge about the insecurity of a given system they are using. In fact, they suffer from the state of false security, where their sense of security is based on ignorance, not on the true state of their risk.  Disclosure gives the good guys an opportunity to address the issue in both the short and longer term.

The bottom line is that those of us in the IT security world live in an interesting and complex reality. Overall, security defenses are not keeping pace with the expanding attack surface, and attackers are becoming increasingly industrialized and resourced. This is a toxic combination.  One hope is that threat research conducted by white hats can help tip the balance. But the disclosure of this potentially sensitive research must be done responsibly.

Matthew Gardiner is a Senior Product Marketing Manager at Mimecast and is currently focused on email security, phishing, malware, and cloud security. With more than 15 years focused in security, Matthew's expertise in various roles includes threat detection & response, ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Commentary
Ransomware Is Not the Problem
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  6/9/2021
Edge-DRsplash-11-edge-ask-the-experts
How Can I Test the Security of My Home-Office Employees' Routers?
John Bock, Senior Research Scientist,  6/7/2021
News
New Ransomware Group Claiming Connection to REvil Gang Surfaces
Jai Vijayan, Contributing Writer,  6/10/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-24376
PUBLISHED: 2021-06-21
The Autoptimize WordPress plugin before 2.7.8 attempts to delete malicious files (such as .php) form the uploaded archive via the "Import Settings" feature, after its extraction. However, the extracted folders are not checked and it is possible to upload a zip which contained a directory w...
CVE-2021-24377
PUBLISHED: 2021-06-21
The Autoptimize WordPress plugin before 2.7.8 attempts to remove potential malicious files from the extracted archive uploaded via the 'Import Settings' feature, however this is not sufficient to protect against RCE as a race condition can be achieved in between the moment the file is extracted on t...
CVE-2021-24378
PUBLISHED: 2021-06-21
The Autoptimize WordPress plugin before 2.7.8 does not check for malicious files such as .html in the archive uploaded via the 'Import Settings' feature. As a result, it is possible for a high privilege user to upload a malicious file containing JavaScript code inside an archive which will execute w...
CVE-2021-24379
PUBLISHED: 2021-06-21
The Comments Like Dislike WordPress plugin before 1.1.4 allows users to like/dislike posted comments, however does not prevent them from replaying the AJAX request to add a like. This allows any user (even unauthenticated) to add unlimited like/dislike to any comment. The plugin appears to have some...
CVE-2021-24383
PUBLISHED: 2021-06-21
The WP Google Maps WordPress plugin before 8.1.12 did not sanitise, validate of escape the Map Name when output in the Map List of the admin dashboard, leading to an authenticated Stored Cross-Site Scripting issue