Privasec’s Ridiculous Claim of a “World Record” in Vulnerability Disclosure

On May 9, 2019, Privasec published an odd press release with a URL slug of “privasec-queensland-telstra-acquisition” but a title of “Privasec Red’s Consultant Breaks World Record By Disclosing Most Number Of Open-Source CVEs.” This claim is simply wrong. To believe it requires either a complete understanding of the vulnerability disclosure landscape or intent to deceive. Neither is a good look for a security company.

The Claim

The claim that Sajeeb Asim Lohani (a.k.a. sml555 a.k.a. ProDigySML) has disclosed 120 vulnerabilities and it is a record that is fairly trivial to debunk. I say fairly trivial because it requires a good vulnerability dataset that tracks creditee information. Since CVE / NVD do not do that, I am curious how Privasec came to their conclusion. SecurityFocus’ BID and IBM X-Force are public databases that track creditee, but neither allow for a way to readily poll for that statistic. Even scraping that data, mangling it, and making a local searchable dataset should quickly show that 120 is probably not the record. [Update: IBM XFD shows 60 total]. So Privasec’s first mistake is not disclaiming how they determined their claim.

The Debunking

Using VulnDB, which also tracks creditee and makes it easy to search along with statistics around the researcher, I don’t even see 120 vulnerabilities creditee to Lohani. This is after combining three separate creditees, Lohani, sml555, and ProDigySML, that were all one into a single creditee. That yielded 78 vulnerabilities:

Why 78 vs the claimed 120, regardless if the most or not? There are several possibilities here and they may be mutually inclusive. The easiest explanation is there are over 40 disclosures by Lohani that have not been aggregated by VulnDB. Given the historical data and thousands of sources monitored, that would be a bit suspect. Given that he “was nominated for AISA Rookie of the Year in 2017“, that suggests this isn’t an issue of disclosures being historical and the data being incomplete.

Another possibility is that Privasec is trying to hide behind a single word in this press release. Note that it says he “has broken the world record by privately disclosing 120 Open-Source CVEs.” The problem with trying to use this as an out is that how do they know how many other vulnerabilities were privately disclosed? Besides, they also make a point to say “Open-Source CVEs”, which presumably means “public” CVEs. This on top of the PR headline not qualifying their claim at all.

One last possibility is that there are over 40 more of his vulnerabilities with a CVE, but all in RESERVED status. If that was the case, you’d expect them to have contacted MITRE to get them published; after all, they do say “open-source” Additionally, they likely don’t have knowledge of the RESERVED entries that are actually public, which numbers in the thousands.

The Counter

If not Lohani, who has the most vulnerabilities to their name? Probably Mateusz Jurczyk (j00ru) but I would have to do some more data massaging to verify it. He (1,717) and Gynvael Coldwind (1,143) both come to mind for an incredible number of vulnerabilities, many disclosed together. Another name from a ways back is r0t (811), who rode the web application wave with many XSS and file inclusion vulnerabilities. Compare any of those to Lohani with his 120 claim as the “world record” and you can see it is quite absurd. Hell, Jurczyk has more Microsoft Windows vulnerabilities with a CVE assignment than Lohani has in total. It’s clear Privasec didn’t do their homework, or simply didn’t care to.

The Offer

Am I wrong? Possibly. I outlined several reasons why the numbers might be off on either side. So I have an offer for Lohani and Privasec; prove me wrong. It’s quite simple too, since you have the data used for the 120 figure. Share a list of Lohani’s vulnerabilities with me. A simple list of the CVE IDs is all I need, I will do the heavy lifting to verify that number is accurate. You’re still wrong about that “world record” either way, that is proven above. But I would love to see the list of 120 you claim regardless.

The Charity Challenge for Banshee

Unfortunately for them, the fax machine was invented in 1843. Banshee admitted defeat, so Durian it is! But I wanted to give some encouragement and started a charity pledge drive. Of course, me being me, I created a tracking sheet for this and as of this blog, there is already $1945 in pledges to help support Love and Justice in the Streets.

Since Durian isn’t in season, Banshee is going to consume it at the next DEF CON in front of witnesses to make it official. Until then, I’d love to see more pledges! Send me a tweet and tag @banasidhe in it!

Exotic Tropical Tropical Fruit Durian Malaysia

Forbes: Lazy Vulnerability Reporting & A Bit of Bias

It may have been almost two decades ago, I joked with colleagues that many Information Security news articles could just be done via Mad Libs. We later joked that breach notifications often appeared to be done via Mad Libs, using the same phrases with different organization names and the number of affected customers. Over the last few years, it seems Forbes has gotten lazy in their reporting on computer vulnerabilities.

First, a bit of background by querying Risk Based Security’s VulnDB, which I work on. While we track news articles on vulnerabilities, it is important to note that it is done in a best faith effort. We try to capture higher profile articles in the bigger publications within InfoSec and those outside the proverbial “echo chamber”, which includes Forbes, New York Times, Washington Post, Fox, etc. So by no means is this comprehensive, but it is important to understand the methodology which is using Google Alerts based on “CVE” strings. This started several years ago, maybe around 2015 give or take. Articles included before that were as they came across social media, referenced in modern disclosures, or some other current manner despite the publication date.

The first Forbes article we have associated goes back to June 17, 2001, covering a vulnerability in a GE Healthcare device. Up to 2010, almost every Forbes article we have is in a GE device along with one about Oracle and one about Linux Kernel. That alone is kind of interesting. From 2010 to 2020 we have Forbes articles covering a wide variety of vendors including Google, Onity, GE, Apple, Magento, PLX, and more. They also included articles covering big disclosures that covered multiple vendors of DVR systems, SIM cards, micro processors, and more. Last year, in 2020, Forbes produces a steady stream of articles for all the big vendors including Cisco, Microsoft, Apple, Google, Intel, Citrix, Zoom, and more.

This year though, it seems like Forbes got lazy. Perhaps it is burnout writing what is essentially the same article? You might think that, but no, because that is exactly what they started doing. Coverage is heavily based around Google Chrome and components in it, but disclosed via Google Chrome’s blog. Of the 48 vulnerabilities in 2021 cataloged by VulnDB, that have an associated Forbes article, only 12 are in non-Chrome products. What’s the gist of their coverage? Here’s three examples, see if you notice the similarities.

You may see the common phrase, “2 Billion Chrome Users”. Don’t worry, in a recent article that got increased to 2.6 billion! If it isn’t in the headline, you can find the phrase in almost every article talking about Chrome vulnerabilities. I get that these articles are repetitive, because there are only so many ways you can say Google fixed vulnerabilities in their browser.

That said, what’s more interesting to me is that they appear to have a single similar article for Mozilla Firefox vulnerabilities in all their time while continuing to encourage users to ditch Chrome. If I didn’t know better, I might think Forbes has chosen a side in the browser wars.

An 83 Word Excuse Instead of a 1 Character Fix (NCSC.nl)

The National Cyber Security Center of the Netherlands (NCSC.nl) has a curious take on sharing security information. On October 25, 2021 I contacted them to inform them of a simple typo in one of their advisories. I send mails or Tweets like this several times a week to researchers, vendors, and news outlets as CVE typos are prevalent. The issue is that a mistyped CVE ID can cause a lot of headache for organizations that take vulnerability intelligence seriously. Imagine an alert about a new CVE affecting enterprise software running your most critical assets and you can only find a news article on it saying the issue is critical. The vendor advisory doesn’t reference it and almost nothing to be found on Google or social media. What do you do? Before you spin up the entire team and tell them to stay late planning for emergency remediation, you need to know what you are dealing with.

Most of the time, the Tweets and emails get a quick reply acknowledging it was a typo and they fix it when possible. Every so often I get no reply and the typo stays there, likely forever. That typically happens on sites that appear to be automated aggregation of content for the sole purpose of getting clicks to generate ad revenue. They have no contact information, no social media, and no author bylines. Otherwise, generally such notifications are well received.

In the case of NCSC.nl I figured I would get a prompt reply and a quick fix. I got the prompt reply, but not the fix. First, note that they provide limited advisory services notifying their stakeholders of vulnerabilities and a page describing what the advisories are. They also have a PDF with a bigger explanation of what a security advisory is. Per Google translate, the advisories “… aim is to describe what the vulnerability is and what could possibly happen if it is exploited.” Simple and straight-forward. As most security professionals know, accuracy in an advisory is important. A typo in a CVE could point to the wrong vulnerability which might be the wrong software completely, or the right software and the wrong vulnerability. I contacted their info@ to let them know about the typo:

https://advisories.ncsc.nl/advisory?id=NCSC-2021-0840

[..] CVE-2021-3715 , CVE-2021-38160 , CVE-2021-4049 [Link]

That should be CVE-2021-40490 at the end.

Brian

The prompt reply I received the next morning was rather baffling. They ‘investigated’ the issue, confirmed I was correct, and wrote a 62 word reply over six lines instead of just fixing the single character that was missing.

Thank you for your e-mail. Hereby we confirm that we have received your
email and investigated the issue. We would like to thank you for your
friendly remark. However, we have decided not to update the
advisory as the CVE number is written correctly in other places in the
advisory.
Feel free to contact us again if there are any questions left.

I naturally questioned them on this odd reply and refusal to fix an inaccurate CVE identifier:

Yes, I have questions.

Why wouldn’t you correct a simple typo? More specifically, for a CVE ID that can cause confusion for security practitioners trying to ensure they have accurate vulnerability intelligence. Anyone reading your advisory may go down a proverbial rabbit hole trying to figure out what CVE-2021-4049 represents and waste considerable time.

Consider that that typo caused our team to respond trying to figure out what that ID represents. Fortunately, we have amazing vulnerability intelligence and it was fairly easy to deduce what happened.

Your apathy in this matter is staggering.

I hoped that an explanation, with a bit of shaming, might prompt them to just fix the single missing character. Nope…

Thank you for your e-mail. We appreciate your concerns. When the advisory
needs to be updated the typo will be corrected.

OK, but the advisory literally needs to be updated to fix the typo. This recursive excuse is just absurd. 21 word reply this time instead of a one character fix. They appreciate my concerns, but not enough to fix ONE CHARACTER.

It’s hard to have faith in Information Security when a national security center doesn’t understand the importance of accuracy and integrity. I hope organizations in the Netherlands are not relying on the NCSC.