Perlroth, Miller, and the First Remote iPhone Vuln

In what is sure to be my last blog (?!) born out of reading “This Is How They Tell Me The World Ends” by Nicole Perlroth, this article is basically a quick dive into a single paragraph that contains one sentence with an alleged fact pertaining to vulnerability history. As a self-described Vulnerability Historian, this is of course of interest especially if the statement is questionable. From page 63 of the book, here is the paragraph for full context and the relevant bits in bold:

But that’s not how he would be remembered. One month after unleashing his white paper on the world, Charlie [Miller] made an even bigger name for himself with the first remote hack of an iPhone. The conventional wisdom had always been that the iPhone – with its sleek design and closely held code – was more secure than the alternatives. But Charlie blew a hole right through that theory. He demonstrated before an audience of hundreds how easily he could remotely control anyone’s iPhone simply by steering their browser to a malicious website he created.

With that, we’ll examine three components of this claim:

  1. Was the vulnerability remote?
  2. Was the vulnerability in an iPhone?
  3. Was Miller the first?

Before jumping to conclusions on those answers, there’s a twist or two! If you’re already grumbling over me being “wordy” you can scroll down to the end for the cliff notes TL;DR and miss the rabbit hole adventure. And also thank me for not posting each section separately, teasing it out and making you wait two weeks for an answer.

Was it Remote?

Perlroth cites the quoted section above from a 2007 article by John Schwartz titled “iPhone Flaw Lets Hackers Take Over, Security Firm Says“. To make sure we understand the context from this article, with an important bit highlighted:

Once he was there, the site injected a bit of code into the iPhone that then took over the phone. The phone promptly followed instructions to transmit a set of files to the attacking computer that included recent text messages — including one that had been sent to the reporter’s cellphone moments before — as well as telephone contacts and email addresses. “We can get any file we want,” he said. Potentially, he added, the attack could be used to program the phone to make calls, running up large bills or even turning it into a portable bugging device.

For clarity, and to show this was widely reported, we see from Farhad Manjoo of Salon in his article “Security researchers find a dangerous iPhone flaw” that the attack vector is stated more clearly:

The hack — first reported by John Schwartz in Monday’s New York Times — can be activated through a malicious Web site, a Wi-Fi access point or a link sent to the phone through e-mail or a text message. After it’s activated, an attacker can make the phone transmit files or passwords, run up wireless services or even record audio and relay it back to the attacker.

The reason the attack vector is so important is that it speaks to the first part of the claim in which Perlroth says it was the “first remote hack”. In the context of vulnerabilities, remote means that a vulnerability can be exploited remotely without user interaction from the victim. If the exploit requires the victim to perform an action of any kind, including clicking a link, it is a user-assisted or context-dependent attack. While that is a serious attack, since we know the bar for clicking a link is low, it is still important to make this distinction. Why? Let’s start with risk scoring and refer to Remote Code Execution (RCE) and Arbitrary Code Execution (ACE) for reference.

Using the Common Vulnerability Scoring System (CVSS), an industry standard for better or worse, we get four sets of scores to look at. First, understand that many organizations use a three-tier “stoplight” system for general risk severity (i.e. low, medium, high) or a five-tier system that adds an ‘informational’ and ‘critical’ rating. The five-tier system breaks down as 0.0 (informational), 0.1 – 3.9 (low), 4.0 – 6.9 (medium), 7.0 – 8.9 (high), 9.0 – 10.0 (critical). For organizations that prioritize at this higher level first, focusing on critical before moving to high-risk, the difference between an 8.9 and 9.0 may mean a lot. So let’s compare a RCE versus an ACE looking at both CVSS version 2 and 3, which are the same in spirit but different in implementation:

As we see, arbitrary code execution under CVSSv3 is scored as 8.8 which is only “high” risk while under CVSSv2 it is “critical”. Compare that to remote code execution which is “critical” under both scoring systems. So the distinction between remote and user-assisted is important in both severity and factual accuracy. Jumping back to specifics of the attack:

The hack — first reported by John Schwartz in Monday’s New York Times — can be activated through a malicious Web site, a Wi-Fi access point or a link sent to the phone through e-mail or a text message.

This is clearly an arbitrary code execution situation as it requires a victim to visit a malicious web page in some manner. That distinction is one that Charlie Miller has made himself many times over the years. This is not a remote vulnerability. At this point it would be more accurate to say “first user-assisted code execution vulnerability in an iPhone“. That’s a bit different huh?

Was the vulnerability in an iPhone?

The simple answer is of course, “yes”. But it’s more complicated than that which we’ll see, as well as why that is important. When attributing a vulnerability to a given device like an iPhone we should note if the vulnerable code is in Apple’s own iPhone code or a third-party library used by the device. This distinction starts us down a rabbit hole.

First, we’ll reference the vulnerability in question which is CVE-2007-3944, and it was cited in the iPhone v1.0.1, macOS Security Update 2007-007, and Safari 3 Beta Update 3.0.3 updates:

Safari

CVE-ID: CVE-2007-3944

Available for: iPhone v1.0

Impact: Viewing a maliciously crafted web page may lead to arbitrary code execution

Description: Heap buffer overflows exist in the Perl Compatible Regular Expressions (PCRE) library used by the JavaScript engine in Safari. By enticing a user to visit a maliciously crafted web page, an attacker may trigger the issue, which may lead to arbitrary code execution. This update addresses the issue by performing additional validation of JavaScript regular expressions. Credit to Charlie Miller and Jake Honoroff of Independent Security Evaluators for reporting these issues.

How do we know it was this vulnerability and not a subsequent one? Perloth says it came one month after Miller’s paper, “The Legitimate Vulnerability Market” from May, 2007. Miller and Honoroff’s vulnerability was shared with Apple on July 17 and publicly disclosed on July 19. Close enough to a month and the next iPhone update was 1.1.1 in September which did not credit Miller. You can also notice that while Perlroth credits Charlie Miller, it was additionally credited to a second individual, Jake Honoroff. 

We can see that the first two advisories attribute the vulnerability to the code in Safari, while the Safari advisory attributes the vulnerability to WebKit, an open-source web browser engine used by Google Chrome, Apple Safari, Mozilla Firefox, Microsoft IE (recent versions) and other browsers. But the advisory tells us the issue is actually in Perl Compatible Regular Expressions (PCRE), which is a library used within a library (WebKit) used within Safari used within the iPhone. At this point it would be more accurate to say “first user-assisted code execution vulnerability in a transient dependency used by the iPhone“. That’s quite different huh?

We need to go further down the rabbit hole though. Since the vulnerability is in WebKit, which existed before the iPhone and the first security patch, we need to consider if any prior WebKit vulnerabilities might have impacted the iPhone and simply weren’t reported as such. We know iPhone development began in 2004 and the first release was June 29, 2007. We don’t know what that development was like, specifically how often they pulled in upstream code in WebKit. In theory that gives us a 3.5 year window but I think it is safe to say the developers would pull in code more often. There are at least two WebKit exploits from 2006, only one later in the year disclosed on November 14 that is ACE. I’d suspect that was patched well before the iPhone release since it was patched in macOS at that time.

Next we need to consider if other Safari vulnerabilities might have impacted the iPhone. One vulnerability jumps out quickly, an ACE in Safari patched on June 12, but it only impacts installs on Windows. Next we have a vague disclosure on June 11, 2007 about “ten flaws” in the SVG parsing engine that weren’t reported to Apple (CVE-2007-3718). These very well could represent vulnerabilities that impacted the iPhone, we simply don’t know. There were two more ACE vulnerabilities reported in Safari with no indication they were fixed, just reported (CVE-2007-3187). These could very well affect the iPhone as well. 

Finally, we have to consider if vulnerabilities in other third-party libraries used in the iPhone affect it. Apple doesn’t publish a list of those libraries but based on prior disclosures that affect macOS, which could also affect the iPhone, those include expat, troff, Libxslt, ICU / ICU4C, libXfont, libxml2, glibc, and some FreeBSD BDF font handling code. That’s a lot of code we don’t know about that is certainly a concern.

Did Miller’s vulnerability in question affect the iPhone? Yes, but, at this point it would be more accurate to say “first publicly disclosed user-assisted code execution vulnerability in a third-party library used by the iPhone after commercial sales began“. That’s even more specific huh?

Was Miller the First?

Since the iPhone advisory above covers the first security update for the device, that advisory represents the first batch of vulnerabilities patched after public release. The next thing we need to look at are the other vulnerabilities patched; are any of them ACE or RCE? Yes, one of the four other vulnerabilities is an ACE as well (CVE-2007-2399). It is described as:

Impact: Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution

Description: An invalid type conversion when rendering frame sets could lead to memory corruption. Visiting a maliciously crafted web page may lead to an unexpected application termination or arbitrary code execution. Credit to Rhys Kidd of Westnet for reporting this issue.

So there are two ACE vulnerabilities fixed in the same advisory. How did Schwartz at the New York Times know that Miller and Honoroff’s vulnerability was first? Because Miller likely told him so. In the article Schwartz quotes Lynn Fox from Apple so they talked but I suspect that Schwartz did not verify that information and Fox did not volunteer it. From the NYT article:

The researchers, working for Independent Security Evaluators, a company that tests its clients’ computer security by hacking it, said that they could take control of iPhones through a WiFi connection or by tricking users into going to a Web site that contains malicious code. The hack, the first reported, allowed them to tap the wealth of personal information the phones contain.

[..]

A spokeswoman for Apple, Lynn Fox, said, “Apple takes security very seriously and has a great track record of addressing potential vulnerabilities before they can affect users.”

Per that article and other sources, we know that Independent Security Evaluators (ISE) reported the vulnerability to Apple on July 17. Looking in VulnDB I can see that Kidd reported his find to Apple on June 13, over a month before ISE did, and it is in the third-party library WebKit rather than a transient dependency of WebKit. So that settles it, right? Not quite.

We know that between these two vulnerabilities, Miller was not first. But we also know that neither were remote code execution either. Moving past the iPhone 1.0.1 update, we have to go through each subsequent release to figure out if any of the fixed vulnerabilities qualify. Fortunately, we only have to go one more version to 1.1.1 before we have our first candidate. On September 27, 2007, the update fixed vulnerability in Bluetooth functionality that can be exploited remotely:

Bluetooth

CVE-ID:  CVE-2007-3753

Impact:  An attacker within Bluetooth range may be able to cause an unexpected application termination or arbitrary code execution

Description:  An input validation issue exists in the iPhone’s Bluetooth server. By sending maliciously-crafted Service Discovery Protocol (SDP) packets to an iPhone with Bluetooth enabled, an attacker may trigger the issue, which may lead to unexpected application termination or arbitrary code execution. This update addresses the issue by performing additional validation of SDP packets. Credit to Kevin Mahaffey and John Hering of Flexilis Mobile Security for reporting this issue.

This technically qualifies as the first remote vulnerability in the iPhone! However, notice that it has to be exploited from within Bluetooth range which severely limits exploitation. In such cases CVSS would be scored as AV:A, meaning adjacent network, dropping the score a good bit. While this does fit the bill, meaning Kevin and John deserve serious kudos, it isn’t remote in the context most associate the term with. So let’s keep going to see the first fully remote vulnerability in an iPhone. We pass the releases for 1.1.2, 1.1.3, 2.0, and 2.1 to find the next of interest in 2.2 on November 20, 2008:

ImageIO

CVE-ID:  CVE-2008-2327

Impact:  Viewing a maliciously crafted TIFF image may lead to an unexpected application termination or arbitrary code execution 

Description:  Multiple uninitialized memory access issues exist in libTIFF’s handling of LZW-encoded TIFF images. Viewing a maliciously crafted TIFF image may lead to an unexpected application termination or arbitrary code execution. This update addresses the issue through proper memory initialization and additional validation of TIFF Images.

ImageIO

CVE-ID:  CVE-2008-1586

Impact:  Viewing a maliciously crafted TIFF image may lead to an unexpected device reset

Description:  A memory exhaustion issue exists in the handling of TIFF images. Viewing a maliciously crafted TIFF image may lead to an unexpected device reset. This update addresses the issue by limiting the amount of memory allocated to open a TIFF image. Credit to Sergio ‘shadown’ Alvarez of n.runs AG for reporting this issue.

These two vulnerabilities are interesting because there is a potential for a remote attack here, but the advisory doesn’t make it clear in wording and they don’t provide CVSS scores. Since an image can be delivered a wide variety of ways, including via SMS, the fact that these occur in the ImageIO subsystem is of note. The Apple Developer documentation backs up this thought:

The Image I/O programming interface framework allows applications to read and write most image file formats. This framework offers high efficiency, color management, and access to image metadata.

A bit light on details but this suggests that if e.g. an SMS messaging app, or any other that remotely receives content and processes it, could be an avenue for remote code execution. Based on a chat with a colleague, it would require the victim opening the SMS app at the very least which is a low bar for exploitation, but he does not think the iPhone SMS app renders the images as a preview without clicking into a specific message. Low bar, but still requires some user interaction. We see the exact same thing for CVE-2008-3623 and CVE-2009-0040 in the iPhone 3.0 update on June 17, 2009. It is interesting to note that we’re now two years after the iPhone’s release and full remote vulnerability with no limitations or caveats.

CoreGraphics

CVE-ID:  CVE-2008-3623

Impact:  Viewing a maliciously crafted image may lead to an unexpected application termination or arbitrary code execution

ImageIO

CVE-ID:  CVE-2009-0040

Impact:  Processing a maliciously crafted PNG image may lead to an unexpected application termination or arbitrary code execution

This time, one of them is in CoreGraphics which does not seem to be as promising as ImageIO based on the documentation. Moving on we land on the iPhone 3.0.1 update released July 31, 2009 and see:

CoreTelephony

CVE-ID:  CVE-2009-2204

Impact:  Receiving a maliciously crafted SMS message may lead to an unexpected service interruption or arbitrary code execution

Description:  A memory corruption issue exists in the decoding of SMS messages. Receiving a maliciously crafted SMS message may lead to an unexpected service interruption or arbitrary code execution. This update addresses the issue through improved error handling. Credit to Charlie Miller of Independent Security Evaluators, and Collin Mulliner of Fraunhofer SIT for reporting this issue.

This has all the makings of what we’re after. While the advisory says “arbitrary code execution” that is a qualifier to “decoding of SMS messages”. Receiving the message triggers it as the payload is processed regardless of loading the message specifically. But notice that the same issue was also found by Collin Mulliner. So who found or reported it to Apple first? That is what ultimately settles this question. Since it lists two people with two different affiliations, that typically means mutual discovery or a “vulnerability collision”. 

I reached out to a contact at Apple and asked if they could figure out which of the two sent the email first to settle this debate. Low and behold, I was told that it was a single mail sent June 18, 2009 and both were listed as creditees! That is backed up by a presentation at Black Hat USA 2009 titled “Fuzzing the Phone in your Phone” given by both individuals.

Conclusion (tl;dr)

We began the blog with a quote from Nicole Perlroth’s book, “This Is How They Tell Me The World Ends”, in which she says “One month after unleashing his white paper on the world, Charlie [Miller] made an even bigger name for himself with the first remote hack of an iPhone.”  The question is if that quote is accurate, understanding she is citing CVE-2007-3944. The answer is, it’s complicated. Here’s the facts as best I can tell:

  1. Was it remote? No, the cited vulnerability is a user-assisted issue and cannot be carried out remotely w/o that victim clicking something.
  2. Was the vulnerability in an iPhone? Kind of. The vulnerability was in the Perl Compatible Regular Expressions (PCRE) library used by the JavaScript engine in Safari, bundled with the iPhone. Yes it affected the device, no the vulnerability wasn’t in Apple’s code let alone the iPhone native code base.
  3. Was Miller the first? It’s complicated. 
    1. If we go strictly by CVE-2007-3944, then no Miller was not the first. Rhys Kidd disclosed a user-assisted vulnerability in WebKit, the rendering engine in Safari, over one month earlier. Further, Jake Honoroff co-disclosed the vulnerability Miller found.
    2. If we go by remote without interaction but limited in attacker location, then no, Kevin Mahaffey and John Hering are the first with CVE-2007-3753 that must be exploited over Bluetooth.
    3. If we go by the actual first remote vulnerability, CVE-2009-2204 around two years later, then yes but Miller co-discovered it with Collin Mulliner and both earned that distinction.

In short: no, kind of, no, no, yes but. So Perlroth is incorrect in her assertion and very likely included it after talking to Miller for her book. The problem is that in the context of the 2007 vulnerability, Miller was wrong and Perlroth et al did not properly fact check that detail, instead relying on a co-worker’s article as gospel. We don’t know if Miller mentioned Honoroff in his discussions with Perlroth or if her text was written outside the scope of her discussion with Miller, but that detail was trivial to find if the claim was fact checked beyond her colleague’s article that also omitted it.

Regardless, I believe we have a definitive answer as to that one line in the book. It took eight pages to get to this answer and I apologize for that (not really).

Zero-days: Two Questions from Perlroth

I am currently reading “This Is How They Tell Me The World Ends” by Nicole Perlroth, only on page 17 in Chapter 2, so a long ways to go before completing the 471 page tome. While only 17 pages in, there are already some annoyances to be sure, but the tone, scope, and feel of the book is enjoyable so far. I am not sure if I will do a full review at the end or perhaps write some blogs specific to topics like this one. It obviously didn’t take long at all to get to the point where I thought a quick blog with my perspective might be interesting to some.


At the end of Chapter 1, Perlroth summarizes what she sees as the long road ahead for her to tackle the subject of zero-day exploits. This follows her describing one dinner with a variety of security folks from all sides of the topic but seems to center around two zero-day exploit writers not answering some ‘basic’ questions like “who do you sell to?” She uses this to enumerate a list of questions around the topic of zero-day exploits that she would have to face to cover the topic thoroughly. Of the 28 questions she posed to herself, two stood out to me but requires two more to better set the stage:

Who did they sell their zero-days to?
To whom would they not?
How did they rationalize the sale of a zero-day to a foreign enemy? Or to governments with gross human rights violations?

Depending on who you ask, or when you ask them, you may be told these are simple questions and answers, very complex, or like an onion.


When you ask if an exploit broker will sell to governments with “gross human rights violations“, that gets complicated in today’s world of geopolitics while remaining much more simple as far as morals and ethics go. If gross human rights violations are the line in the sand, meaning regular human rights violations are acceptable (?), then it cuts out all of the biggest players in the game; United States, China, Russia, North Korea, and Iran. Before any of my European friends head straight to the comment section, I am not forgetting or neglecting you. Some of the European countries maintain teams that are extremely accomplished and arguably better than the countries I listed. Why? You don’t see their names being splashed in every other headline and attribution claim. Further, some of the most elite zero-day writers from the late 80’s and early 90’s were European. I used to be privy to a handful of some of those exploits and on occasion, brokered (traded, not sold) them between groups. Further, I don’t associate most European countries with the other five as far as gross human rights violations, at least not in recent history.

Since zero-day exploit writers do sell to some of those countries at least (US, CN, RU), and presumably some sell to the other two (IR, KP), now we’re talking shades of grey or onions, depending on your favorite analogy. You’re left trying to draw a line in the sand as to which human rights violations you can accept and at that point, does the question even have relevance? I don’t want to get into a pissing war over who is holier or more evil than the other because each of the five countries above has their long list of sordid atrocities.


Let’s jump back to the third question there, the notion of “foreign enemy”. This is peculiar since the book had already thrown around the term “mercenary” several times in the prologue, and that scenario answers the question simply. A mercenary sells their services to the highest bidder typically, ethics takes a seat in the trunk if it even comes along for the ride. So a simple summary is that some will sell to the highest bidder, end of story.

But does any of the above really matter? Long ago I heard a great quote that is both funny and sardonic, that I think has relevance to the other question:

“We refuse to join any organization that would have us as a member.”

If we’re discussing the notion of being involved with another group (country in this case), isn’t the ethics of selling a zero-day that you know will potentially be used against your own country a lesson in abject self examination? If you are willing to sell to such an organization, one that might cause a power outage, risk human life, or undermine security and privacy as only a nation-state can, is that the kind of organization you want to be a part of? If such an organization or country is willing to buy zero-day exploits from you to use for those purposes, is that the type of organization you want to be affiliated with?

If the answer is no, then Perlroth has the beginning of her answer. If the answer is yes, then we’re back to square mercenary. Pretty simple maybe?

Commentary on Radware’s Top Web Exploits of 2020

At the close of each year we see at least one article covering the top vulnerabilities / exploits from the prior year. This is usually written on the back of having large detection networks across the Internet that get a comprehensive view of exploitation. It’s a great way to get real intelligence for criminal hacking activity. Unfortunately, we often see a breakdown when it comes to conveying that information in a useful manner. I know there is an argument to be made that the companies releasing such blogs are primarily after PR, sure. But they also have an opportunity to help their clients and the rest of the world by ensuring the blogs contain more useful and actionable information.

For this commentary, I’ll examine Radware’s blog, “The Top Web Service Exploits in 2020” published December 23, 2020 and covered almost verbatim by Security Magazine on January 5, 2021. I don’t have a view into exploit activity itself, but I do have a good view into the vulnerability disclosure landscape that is a cornerstone of this commentary.

We’ll start by setting a few basic ideas for mutual understanding for any such blog. First, each exploit should be tied to a unique vulnerability or it should explain it is an exploit chain and clearly delineate each vulnerability in the chain or explain what it represents if not a pure vulnerability. Second, it should provide at least one external reference for each vulnerability; either a CVE ID, vendor advisory, or commonly accepted third-party advisory such as US-CERT or another similar body. This is what allows the reader to quickly determine if their organization has patched against the vulnerability or not. If I have to spend considerable time trying to determine which vulnerability is being described, many organizations may be at a complete loss trying to figure it out.

With that, let’s look at the top 10 exploited vulnerabilities in 2020, according to Radware, and try to figure out some additional information for perspective. I will also be very clear that Radware’s blog is extremely frustrating and not immediately helpful, instead requiring a lot of extra work. The fact that they only attributed three exploits to a CVE ID is a dismal commentary on the CVE ecosystem. This analysis of their analysis will server as a reminder that comprehensive vulnerability intelligence is the foundation of any good security program.


Service Exploit #1: /ws/v1/cluster/apps/new-application

Based on their description, this appears to match VulnDB 184750 “Apache Hadoop YARN ResourceManager REST API Request Handling Remote Command Execution“. The first thing of interest is it was disclosed on October 19, 2016 and does not have a CVE assignment over four years later. No wonder many organizations aren’t aware of this vulnerability and have not sought out their own remediation strategy.

Service Exploit #2: /manager/html

This is summarized as “Apache Tomcat Manager Application Upload Authenticated Code Execution” and goes on to describe it as “This module can be used to execute a payload on Apache Tomcat servers that have an exposed “manager” application. The payload is uploaded as a WAR archive containing a JSP application using a POST request against the /manager/html/upload component.

Despite this description, that does not cleanly map to any vulnerability in VulnDB. The closest matches are CVE-2017-12615 and CVE-2017-12617 which is an abstraction for different platforms, but fundamentally “Apache Tomcat HTTP PUT Method JSP File Upload Remote Code Execution“. On the surface this is a match with Apache Tomcat, JSP application, and POST request to achieve code execution. However, those two CVEs cover a JSP file upload, not a WAR archive, and do not mention the /manager/html/upload component. So we’re left wondering if the exploit described is simply a misconfiguration scenario (i.e. intended functionality not secured) or an actual disclosed vulnerability.

Service Exploit #3: /level/15/exec/-/sh/run/CR

Based on the description, this is a misconfiguration scenario where an administrator sets up a Cisco router with the HTTP admin interface enabled, but without password protection. This allows an attacker to use the legitimate functionality to run arbitrary commands.

Service Exploit #4: /admin/assets/js/views/login.js

Radware says this “resource belongs to Sangoma FreePBX code and it looks like the attackers are trying to detect vulnerable FreePBX servers and exploit one of the known vulnerabilities.” The first issue is that script doesn’t immediately track to a VulnDB entry based on titles, which reflect the script name typically. However, let’s consider the URL being seen: … login.js. Rather than attempting to exploit “one of the known vulnerabilities“, I would suggest instead they are trying default credentials. At least back around 2000, the tried-and-true default credentials of admin/admin were all you needed to access the interface.

This one is curious to me because presumably a company that was detecting exploit traffic and could see e.g. POST requests as demonstrated in Service Exploit #2, would also see that the attackers were trying the default credentials. So we’re left with Service Exploit #4 being of little help and only creating confusion over what is being exploited.

Service Exploit #5: /ftptest.cgi?loginuse=&loginpas=

Radware attributes this to “many cheap Wireless IP web cameras use the same genetic code based on the GoAhead code (the tiny, embedded web server).” This tracks cleanly with VulnDB 181032 “Axis Multiple Products axis-cgi/ftptest.cgi Multiple Parameters Remote Command Execution Weakness“. This is actually a fun rabbit hole as this disclosure originally comes from an audit of a AXIS A1001 Network Door Controller and exploitation of this issue requires privileged access to the management interface. With that in mind, we’re back to a default credential scenario that may be the actual issue. Back in 2001, defaults for Axis network cameras were covered by CVE-2001-1543.

[Update: Z Balazs points out that this finding is likely due to Persirai botnet activity and links to more information.]

Service Exploit #6: /service/extdirect

This is the only one of the ten exploits covered that they include a CVE ID for. CVE-2019-7238 maps to VulnDB 198437 “Nexus Repository Manager /service/extdirect Insufficient Access Control Request Handling Remote Code Execution“. But, is that really the right ID? If we look at CVE-2020-10204 we are given a very brief summary of “Sonatype Nexus Repository before 3.21.2 allows Remote Code Execution” and a link to the vendor advisory. However, VulnDB 226228 also maps to this and is summarized as “Nexus Repository Manager /service/extdirect Request Handling Remote Command Execution“. We immediately see the /service/extdirect from Radware’s finding in both titles. The vendor’s advisory does not include this endpoint though, but we find it in this exploit published on GitHub that tracks with the CVE-2020-10204 and we see it in a different exploit for CVE-2019-7238.

CVE-2019-7238 was fixed in Nexus Repository Manager version 3.15.0 and CVE-2020-10204 was fixed in version 3.21.2. Due to the vague vendor advisories it difficult to tell if this was a regression situation or something else. But, the CVE-2020-10204 vendor advisory gives us the interesting bit in the context of exploitation: “The vulnerability allows for an attacker with an administrative account on NXRM to execute arbitrary code by crafting a malicious request to NXRM.” That is an important distinction! So this is likely CVE-2019-7238 as Radware says, unless there are default credentials which would allow for exploiting CVE-2020-10204 as well.

Looking at the NVD entry for CVE-2020-10204 we also see that they scored this incorrectly for their CVSSv3 score, as ‘Privileges Required‘ should be ‘High‘, notLow‘ as they have it.

Service Exploit #7: /solr/admin/info/system?wt=json

For this one, we get an Apache Bug ID (SOLR-4882) and CVE-2013-6397 as references which is great. That said, it would be very helpful if Radware would link to these resources to make it easier for their readers.

Service Exploit #8: /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php

This is the third exploit they match to an ID, CVE-2017-9841 and it was disclosed June 27, 2017. Another good reminder that software with disclosed vulnerabilities and vendor solutions are not being applied, causing many organizations to become low-hanging fruit in the exploit world.

One little nitpick is that the full path they include is likely not how this would manifest on a server. Everything after “src” would be the endpoint being scanned presumably: /Util/PHP/eval-stdin.php

Service Exploit #9: /hudson

With this, we run into another mess and rabbit hole. Radware summarizes this as “Hudson continuous integration tool – multiple vulnerabilities” and further describes Hudson as “a continuous integration tool written in Java, which runs in a servlet container, such as Apache Tomcat or the GlassFish application server. Over the years the project was replaced by Jenkins. The final release. 3.3.3 was on February 15, 2016. Today Hudson is no longer maintained and was announced as obsolete in February 2017.

Based on this description, this could be any one of at least 50 vulnerabilities going back to February, 2014, one of which does not have a CVE ID. 41 of these are in Jenkins software which is mentioned above.

Other Service Exploits

This is a curious conclusion to the “top 10” list, as it states “In addition to the new items that we covered in this list, we have also seen items that we already saw and covered in our previous blog Top 10 Web Service Exploits in 2019 such as /ctrlt/DeviceUpgrade_1, /TP/public/index.php and /nice%20ports%2C/Tri%6Eity.txt%2ebak.

That isn’t exactly a #10 on this list, rather a catch-all for “other stuff we saw including…“. The first listed tracks with VulnDB 170573 “Huawei HG532 Routers /ctrlt/DeviceUpgrade_1 NewStatusURL Element Remote Command Execution (Satori)” which is notable as it is used in Satori, a Mirai botnet variant.

The second tracks with VulnDB 194379 “ThinkPHP /public/index.php call_user_func_array() Function vars[1][] Parameter Remote Code Execution“. Note the different exploit path and we see it can actually be exploited via several endpoints according to analysis of the vulnerability by Knownsec 404 Team.

The third doesn’t immediately track with an entry in VulnDB. Radware gives us “/nice%20ports%2C/Tri%6Eity.txt%2ebak” which we can decode to a more friendly “/nice ports,/Trinity.txt.bak“. A quick Google for that request finds a blog from Dragos titled “Threat Hunting With Python Part 2: Detecting Nmap Behavior with Bro HTTP Logs” explaining this request:

The request for “/nice ports,/Trinity.txt.bak” comes from Nmap’s service detection routine testing how a server handles escape characters within a URI. The actual request is “GET /nice%20ports%2C/Tri%6Eity.txt%2ebak HTTP/1.0\r\n\r\n”.

So this isn’t an actual exploit, rather, it indicates that attackers are using the Nmap port scanner. This is a good reminder that “exploit scanning” doesn’t always cleanly map to a specific vulnerability.


Detecting exploitation is critical for every organization. Doesn’t matter if it is on-premises devices or a managed service-based detection. What is more critical is having comprehensive and timely vulnerability intelligence that can turn what you detect into actionable information. This is how you not only detect, but evaluate and remediate, assuming of course the vulnerability is known to the vendor or a mitigation can be enacted.

Sitting on Undisclosed Vulnerabilities (e.g. SolarWinds Stragglers)

The company SolarWinds is in the news, victims of an attack that compromised their Orion Platform software by inserting a backdoor into it, allowing for remote code execution. Like most big breaches, we hear the term “sophisticated” used for the attack. And like many breaches, we quickly learn that it might not have been so sophisticated after all. There is plenty of commentary on this and the wave of attribution experts are out in full force on Twitter. You can read about all of that elsewhere as I cover a different aspect of vulnerability disclosures here.

For anyone who has done penetration testing, they have found vulnerabilities of course. Since those tests are done under non-disclosure agreements (NDA), the vulnerabilities are reported to the customer. One long-standing problem with process is that a vulnerability found during that test may be in commercial off-the-shelf (COTS) software that affects many other organizations in the world. But that NDA often says you cannot disclose them elsewhere, including to the vendor. Even if it does, most penetration testing shops don’t have someone designated to handle coordinated disclosure with the vendor. When it does happen, it is often in the tester’s spare time or if the company uses security advisories for advertising, may task them to write it up.

For more than 25 years, this means that a lot of vulnerabilities are discovered in COTS that die in customer reports. The customers may sometimes report them to a vendor themselves looking for a fix. But surprisingly, that often does not happen. How do we know? Many testers have seen the exact same vulnerability during a test of the same customer a year or more after the original. There are times where a tester will disclose those vulnerabilities long after the fact, without coordinating with the vendor. This can happen after they leave the company they did the testing for or when they think sufficient time has passed.

I think we saw this yesterday with SolarWinds with the publication of CVE-2018-16243. First, while MITRE is not consistent about the assignment year, CVE is intended to use the year to denote when the vulnerability was discovered, not disclosed. A 2018 ID assigned to an issue that was published yesterday strongly suggests the researcher requested the ID back in 2018 but waited until now to publish. The exact date is likely 8/30/2018 per the disclosure itself. But looking at the disclosure, done via gist.github.com, we can see via the revisions that it was published 12/14/2020. So the researcher appears to have sat on these SolarWinds Database Performance Analyzer vulnerabilities for 837 days. Based on the disclosure, there was no coordination with the vendor and no fix currently available. On the upside, seven distinct XSS vulnerabilities were disclosed but the CVE only covers six of them.

Why now? Because SolarWinds was in the news albeit for a vulnerability in a different product (SolarWinds Orion Platform). Looking at prior vulnerability disclosures, it is easy to tell where the researcher works. A quick LinkedIn search verifies that bit of information and brings us to the fun question; did they find these SolarWinds vulnerabilities at their prior job, the downtime between jobs, or at Optiv? All three have interesting implications if you think about it. =)

Jumping back to the point, I will renew the call I have made in the past; penetration testing shops should use an NDA that allows them to report vulnerabilities in COTS to the vendors on behalf of the customer. They should manage the coordinated disclosure process and publish an advisory after a fix has been made available and they verified their customer has mitigated the vulnerabilities. Yes, it is a little extra work! Yes, it also is a value add to your customer, value to any organization that uses the software, and the advisories become advertising of sorts. That little extra work will go a long way for the greater good.

Not all CVEs are Created Equal. Or even valid…

[I wrote this early 2019 and it was scheduled for January 7 but it apparently did not actually publish and then got lost in my excessive drafts list. I touched it up this week to publish because the example that triggered this blog is old but the response is evergreen. Apologies for the long delay!]

I recently caught a Tweet from @NullCon offering 10 free conferences passes to NullconDasham, awarded to “InfoSec heroes who shared their hard work with the community & contributed to the @CVEnew database“.

I re-Tweeted with comment pointing out “There were at least 311 CVE assignments in 2018 alone, that were for issues that were *not* a vulnerability. I hope you are going to scrutinize the submissions.” Anant Shrivastava replied asking for some examples, and the next morning Mitja Kolsek suggested a blog would be beneficial. Here it is, as short and sweet as I can, which is never short in the world of Vulnerability Databases (VDBs) due to caveats.

Continue reading

Thoughts on 0-days and Risk in 2020

[Stupid WordPress. This was scheduled to publish Nov 23 but didn’t for some reason. Here it is, a bit late…]

On Friday, Maddie Stone from the Google P0 team Tweeted about the 0-day exploits her team tracks. As someone who checks that sheet weekly and tracks vulnerabilities, including ones ‘discovered in the wild’, this is a topic that is squarely in my tiny niche in the industry. Also, big fan of the P0 team!

I replied to her Tweet suggesting it come with a disclaimer that it didn’t represent “all” 0-days, rather they tracked high-end 0-day used primarily in “APT” attacks. Ben Hawkes, manager of the team, replied and agreed with that assessment. Before we proceed, let’s define 0-day real quick since the term is used for a variety of vulnerabilities, often incorrectly.

In this case, the context is a 0-day is a vulnerability that was actually found being exploited in the wild before there was public knowledge of it. In Risk Based Security’s VulnDB, we track that as “discovered in the wild“. Since VulnDB is comprehensive and our goal is to track every vulnerability, regardless of software or severity, we tend to aggregate a lot more than others. As of this post, we have over 78,000 vulnerabilities that aren’t found in CVE / NVD as a point of comparison. In my reply to Maddie I pointed out that we had seen 51 this year compared to their 22.

Next, Allen Householder replied to me asking a fun point, which is how many vulnerabilities did that really represent. Out of the 20,000+ vulnerabilities aggregated in 2020, we have 51 that are flagged as “discovered in the wild”. That represents only 0.25% of all vulnerabilities this year. One point I made previously is that Google’s team likely doesn’t care about a 0-day in the “Adning Advertising Plugin for WordPress” despite it being used to compromise WordPress blogs.

So with that number in mind, it goes back to the narrative that companies need to be scared of 0-days. They absolutely do! But… and this is the big qualifier that needs to come with that fear, is that perhaps they don’t need to be as afraid of 0-days as they do of already public vulnerabilities that they missed. With only 51 0-days in 2020, that means a vast majority of organizations simply aren’t likely to be targeted. Fully patching all known vulnerabilities that impact them should be priority one.

More to the point, vulnerabilities that have functional public exploits allowing anyone to trivially launch a viable attack are consistently a much bigger risk than the elusive 0-days. That is also one reminder of how often times CVSS falls short, if your vulnerability intelligence doesn’t provide Temporal scoring or exploit availability. Organizations making risk decisions only using the CVSS Base score are missing out on an important risk attribute.

I’ll end this blog with some arbitrary statistics around 0-days for fun! These are based on VulnDB data as of 11/21/2020. Note that metadata is less complete before 2012, which includes ‘discovered in the wild’ classification.

  • 241,690 vulnerabilities, only 641 are 0days (0.27%)
  • 14 are in Google products: Chrome (5), V8 (3), Android (6)
  • 146 are in Microsoft products: Windows (63), IE (36)
  • 13 are in Apple products
  • 7 are in Oracle products: Java (4)
  • 62 are in Adobe products: Flash (38), Reader (14)
  • 18 are in security products 😞
  • The oldest is from 1975 in RSTS/E! Yes, for real.
  • The oldest you likely recognize is Sendmail in November, 1983

Disclosure Repair Timelines?

For those in InfoSec, you have probably seen a vulnerability disclosure timeline. Part of that often includes the researcher’s interaction with the vendor including the vulnerability being fixed. After the issue is disclosed, the story typically ends there. Every so often, work needs to be done after that to ‘repair’ part of the disclosure.

For the last year or more I have found myself having to follow-up on more disclosures, specifically because someone on Twitter has posted using an incorrect CVE ID associated with the vulnerability. One of the cornerstones of a CVE assignment is to give it a unique identifier that makes that vulnerability distinct from any others that may be similar. Using the incorrect CVE ID can actually cause a lot of headache for threat intelligence folks that monitor for vulnerability disclosures.

Often times I send a message and within a day the errant CVE ID is fixed. The errors tend to be nothing more than a typo or transposition issue. When fixed quickly and not further indexed by search engines and cited or included by news aggregator sites, the problem is over. Once the errant ID is in several reputable (or somewhat reputable) sources, it is more prone to be quoted in additional blogs and spread from there. Catching and fixing these errors needs to happen quickly, but unfortunately MITRE, the organization responsible for CVE, does nothing in this regards.

The past two weeks, I ran into what is probably the worst case as far as time and effort required to fix a single incorrect CVE. I thought I would share what the timeline looks like as this is not something anyone typically tracks that I am aware of, myself included. But it shows that even after a disclosure more work may need to be done to ensure clarity in it. I’m withholding names because while this time around was difficult, the journalist and publication has quickly fixed other typos in the past. My goal is to show that timely corrections are what is best for the community.

4/30 – Article published citing four CVE IDs, one incorrect.
4/30 – Ping publication/journalist on Twitter
5/1 – Bump thread
5/8 – Bump thread
5/13 – Tweet again asking for a correction
5/14 – Submit site feedback via two different forms
5/14 – Tweet frustration at publication
5/15 – Publication replied to form, didn’t seem to fully understand the point
5/19 – Sent a DM to the author of the article pointing to original Tweet
5/21 – Author replied saying they will fix it. Article amended to fix and clarify the error.

Twenty one days to fix is rough. Publications and journalists; please understand that a CVE ID is important to get right. If you have any questions about CVE, how it works, or the importance, please feel free to reach out. I am happy to take the time to help you.

CVE and the matter of “unique” ID numbers

Common Vulnerability Enumeration, now known as Common Vulnerabilities and Exposures (CVE) is a vulnerability database (ignore their silly claim to be a ‘dictionary’) that the information security industry relies on heavily, unfortunately. Per MITRE’s CVE page, “CVE® is a list of entries—each containing an identification number, a description, and at least one public reference—for publicly known cybersecurity vulnerabilities.” Great, digging a bit deeper into their ‘About‘ page, we get a better definition:

Use of CVE Entries, which are assigned by CVE Numbering Authorities (CNAs) from around the world, ensures confidence among parties when used to discuss or share information about a unique software or firmware vulnerability, provides a baseline for tool evaluation, and enables data exchange for cybersecurity automation.

Please take note that a CVE Entry, or ID number, “ensures confidence” when discussing or sharing information about a vulnerability. Basically, it is supposed to be a unique ID to ensure that confidence. Despite that, any of my dozen loyal Twitter followers will see me constantly pinging researchers, vendors, and the media pointing out that they are using the wrong CVE number to reference a vulnerability. Often times it is a case of not copying and pasting, rather typing it out manually. It is also why in the vulnerability database (VDB) world, we strongly emphasize that copy/paste is the best thing to do in order to prevent transcription errors on an ID that is supposed to be unique.

Sure, it seems pedantic to a degree, but imagine if your doctor decided to manually transcribe a diagnosis code after your visit and you get a call saying you were diagnosed with something completely different. In the vulnerability world, it means you might be vulnerable to something and have no idea if so. If you are, you aren’t sure if there is a solution. Maybe a bit of a dramatic analogy? But.. it holds water, has a bit of recent history, and is the kind that helps administrators better understand the underlying issue.

Instead of sending out a series of Tweets on the latest example, I decided to write a blog to show how these little typos can snowball quickly. Any mature VDB will have a variety of processes to catch wind of a CVE ID that they haven’t seen before. It can be as simple as a live search on Twitter for ‘CVE’ (super noisy) or more technical means. If you run across an unknown CVE you Google it to start, that simple. Today’s example was CVE-2019-0895, which appeared to be a “new windows zero-day”. Exciting in the world of VDBs!

Let me go ahead and spoil things, to make this easier. These articles call it “2019-0895”, but in reality, they actually mean “2019-0859”. A simple transposition of numbers, which is all too common in prior cases. Based on ten-second review, it appears that Fossbytes was the first to transcribe these numbers (Unverified @fossbytes14 on Twitter?). A day later, extremely similar articles appeared on Prodefense (no Twitter and broken Contact form?) and “In Depth IT News / SecNews” which has some serious rendering issues in Chrome. The day after that, Tech Rights references it via a weird embedded link below in an unrelated article [1], and Tux Machines posted about it with key quotes cribbed from other articles, the Fossbytes article in this case.

In each case, it is clear that the offending typo came from Fossbytes. The “In Depth IT News” site even links to https://securelist.com/new-win32k-zero-day-cve-2019-0859/90435/ which has the correct CVE ID in the URL. It is absolutely clear that most of these sites are using automated crap to aggregate content and have no real desire to share accurate news. Each one of them are evidence to the damage caused by a single transposition error from Fossbytes, a “leading source of technology news with a focus on Linux distro releases” … that decided it was important to write about this critical Windows zero day? A critical zero day that is actually ten days old at the time of their article.

OK, hopefully we’re all on the same page here. My Twitter feed is a small graveyard of similar examples from the past few years. Each and every time, the “news” organizations that spread these bad IDs and introduce confusion and questions into the equation, and are the antithesis of a “news” site. Finally, I would like to go on the record about one more bit regarding CVE, which will come as no surprise. On the CVE ‘About’ page, it says CVE is:

Industry-endorsed via the CVE Numbering Authorities, CVE Board, and numerous products and services that include CVE

As a former ten-year veteran of the CVE Board, I do not endorse CVE.


[0] Note: If any of my links show a fixed version of the CVE, good! You can see the originals on archive.today.
[1] This should really be a separate blog post, but it would mostly be cursing around a simple concept; this is the problem with content/link aggregation sites… which are a plague on the Internet. In 2019, they aren’t trying to help, they are desperate attempts to make a few bucks. Disagree? They would have caught this error when they did a quick tech edit pass on the article. But they didn’t, because it is all automated and centered around ‘SEO’ (search engine optimization) so it appears in Google results and you click and see the ads they are serving. I bet if anyone dug deep on such sites, the amount of questionable traffic or malware they delivered might be enlightening. Go back to where this is linked from and notice the URL of the article (/2019/04/18/libreoffice-6-2-3/) and how far you have to scroll to get to the bottom of the page, past all the “content”.

Case Study: Not A Vulnerability (NAV)

[This was originally published on RiskBasedSecurity.com in the 2018 Vulnerability Mid-year Report.]


As stated earlier in this report, “incomplete information, constant updates and revisions, misinterpretation, and errors in reporting can all contribute to a level of confusion regarding the impact, severity and risk a vulnerability represents.” One way that this manifest is in vulnerability reports that disclose what isn’t really a vulnerability. Due to not properly understanding the issue, or overlooking some aspect that already mitigates it, the researcher claims a program is vulnerable when it isn’t. RBS flags these issues as “not a vulnerability” or ‘NAV’ for short.

As a vulnerability database, it may seem counterintuitive to track issues that are not a vulnerability. We would prefer not to! However, there are times where the disclosure is not challenged and persists, leaving the bad information available to the public. This could cause an organization that runs across such an issue to waste time trying to determine if they are vulnerable or implement a workaround when it isn’t needed. In those cases, it is better to include such issues but accurately describe the issue and clearly say that it is not a vulnerability.

Generally, RBS policy is to ignore such a disclosure if it is made in one or two places and doesn’t garner much attention. However, when that non-vulnerability is added to another database e.g. CVE, it becomes important for us to cover it properly. This allows our customers to have timely and accurate information about vulnerabilities and non-vulnerabilities, to help better protect their organizations.

To better understand how often this happens, the following graph shows the number of ‘NAV’ disclosures at the mid-point of each year since 2014, up until the midpoint of 2018. While 2018 currently appears to be less than the two prior years at their midpoints, it still represents a significant number of disclosures that RBS has evaluated and disclaimed as vulnerabilities in order to continue providing the highest quality vulnerability intelligence possible.

Efail: What A Disclosure FAIL That Was!

[This was originally published on RiskBasedSecurity.com.]


Yesterday, news broke of a “critical” vulnerability in OpenPGP and S/MIME, named ‘Efail’ that could lead to an attacker gaining access to plaintext emails. News broke in the form of a dire warning from the Electronic Frontier Foundation warning people to “immediately disable and/or uninstall tools that automatically decrypt PGP-encrypted email.” This was, of course, picked up by various news outlets that ran with headlines varying from slightly alarming to factually wrong and embracing the hype. Potentially impacted vendors had to scramble fast, offering commentary on what the disclosure really means. Today, the researchers released the full paper, titled “Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels”.

In short, the researchers outline an attack scenario against OpenPGP and S/MIME that uses a combination of a known cryptographic attack along with mail clients that do not properly implement a MIME parser. The attack they outline requires access to the encrypted emails, which are then manipulated and sent to the victim. When the victim opens the email and decrypts the contents, a back-channel is established through the use of crafted content in an iframe that is not visible to the user. This general type of attack is well-known, but some email clients that implement OpenPGP or S/MIME may not throw the proper warnings when receiving modified cryptographic content. Overall, there is a high degree of complexity required to exploit these flaws, and it requires the victim to be running a vulnerable email client, load the crafted email, and decrypt the contents. There are several components of this disclosure that are rooted in history.

First, the cryptographic attacks against the Cipher Feedback Mode (CFB) (used by OpenPGP) and the Cipher Block Chaining (CBC) mode (used by S/MIME) have been known since 1999, and more generally known before that. Back in 2000, GnuPG implemented protection mechanisms to detect and warn about modified messages called Modification Detection Code (MDC), which will cause any message that has been modified to throw a clear error message warning the user. GnuPG has said that “ancient versions” (the 1.x line) may be susceptible to this, but any modern version (the 2.x line) is not. OpenPGP implemented protection against malleability attacks since 2001 through the use of authenticated encryption (AE) called Modification Detection Code (MDC). In the coming years, OpenPGP will be implementing a stronger form of AE (EAX or OCB depending on key preferences) that will better protect against these types of attacks. Finally, using iframes to hide content in email has long been used in a variety of spoofing attacks as well as companies using the method to track when an email is viewed.

When the actual paper was published, giving technical details of the vulnerability, it confirmed to many what GnuPG had already said and what was also echoed by an Enigmail developer. While there is an issue that may impact users in some situations, the notion that “encrypted email isn’t safe” is certainly false!

This highlights an ongoing problem we see with vulnerability research that is done to garner as much media attention as possible before disclosing details. We wrote about this a couple years ago with the Badlock vulnerability, where like Efail, the hype and claims before disclosure didn’t live up to the disclosure itself. When getting news coverage is more important than protecting organizations, such disclosures ultimately become a great disservice. Imagine organizations that caught wind of this vulnerability last night or this morning and began scrambling to figure out how to roll out mitigations based on the news articles. Is it really helpful if they disabled encrypted email across the entire organization? We don’t think so. Forgoing all integrated email encryption on the slim chance you may be targeted with this attack just doesn’t make sense. In addition to the hype around the vulnerability, there are two more aspects of this disclosure we’d like to point out that further highlight the problem.

First, the paper includes a list of 36 software-based email clients and 12 web-based clients offered via SaaS that are potentially susceptible. In that list, they say that Mailpile version 1.0.0rc2 is affected. However, according to the vendor, they explain why their software isn’t vulnerable due to a list of defense-in-depth measures they had previously implemented (Note: one researcher disagrees with Mailpile, saying they are still vulnerable, and another disagrees with the disagreement). This calls into question the rest of their affected software list, especially on the back of finding out this vulnerability is not critical as claimed. The second aspect of this disclosure that stands out to us is the last paragraph of their introduction, which states:

Responsible disclosure. We have disclosed the vulnerabilities to all affected email vendors, and to national CERTs and our findings were confirmed by these bodies.

The notion that the researchers performed “responsible disclosure” with this vulnerability is frustrating and misleading. As Robert Hansen points out, he didn’t receive a copy of the report from the researches, though another researcher disagrees saying Hansen was contacted in 2017. While they may have reached out to the impacted vendors, they apparently did not give them time to fix in some cases. Further, their contact with the GnuPG developers almost certainly included details that explained not only how they weren’t vulnerable, but why the issue at hand was not as critical as they claimed. Yet, the paper was released after the news articles promoting how critical the issue supposedly was.

Additionally, we are long-time champions of the more accurate term of “coordinated disclosure” over “responsible disclosure”. The idea of responsible disclosure was pushed heavily by Scott Culp at Microsoft back in October, 2001 and has become polarizing among many in Information Security. After years of pushing back, in 2010, Microsoft opted to drop the term as well due to the problems it caused.

There is a fine balance between using the press as an avenue for better awareness of a critical vulnerability. We understand the concept of naming a vulnerability and creating a web site for it as a one-stop clearinghouse for information on it. However, when time is spent doing that in a way that is misleading to organizations and may prompt them to make poor decisions that negatively impact their security posture, researchers must strongly evaluate their actions and improve their process going forward. This type of disclosure is a reminder that discussing disclosure issues, “responsible” or “coordinated”, is relevant and timely.