Box of Shit: D2D’s Dilemma

Back in 2017, D2D sent me a box of shit. I meant to write about it back then but I got busy, which I think foretold that he would get busy. He now checks in every few months to make one pithy statement, usually about toilet events, and vanish back into his ether. Sometimes his quips are more piss than pithy, especially lately. So this blog may act as a summoning beacon and bring him back to Attrition where he can write more Ruby scripts and screw with Lyger’s directory. Anyway, the box started with an ominous note:

Super observant readers may notice the faint bit on the right, that this is in a Ziploc bag. That doesn’t bode well for me usually.

When I saw these two .. dildos (?) wrapped in separate bags, and more items in the box under it also wrapped, you can imagine I was alarmed. So alarmed I waited to open them until last. So I started with a Dunkin Donuts coozie, a yellow clip, and a stretchy flingy monkey that I promptly shot at a cat. Then I dug in further…

You can see from the full spread that D2D kept up with tradition in fine form. Golf ball, network cable, business cards, lock w/o a key, restraints, remote, his mostly used nail polish, a bag of yogurt cup peel-off caps, part of a four-pack beer container (with a sweet squirrel logo!), a damaged hockey puck (?), protein bar, and enough currency to last me a few minutes in the right country. A solid offering. But then I had to contend with the two wrapped dildo shapes in separate Ziploc bags…. I took the plunge.

Low and behold, for the first time in my life, D2D didn’t let me down and didn’t send me dildos. Instead, I received two epic “Mighty Squirrel” beers from Hopstown. I immediately broke one against the fireplace to make a quick shiv and loudly threaten him, despite being 2,000 miles away. It was reflex and I regret breaking that bottle.

Perlroth, How the World Ends, and Errata

This will be my fourth and very likely final blog on Nicole Perlroth’s book, “This Is How They Tell Me The World Ends”, as far as the subject matter goes. I may write a couple more that are centered around vulnerability history, based on something included in the book, but more along the lines of “setting the record straight” with a broader misconception in the industry that certainly isn’t exclusive to this book. I say ‘may’ because it will depend on my research into a couple of topics.


As I have mentioned in prior blogs, I enjoyed this book. I feel it was very well researched and it offered information about the world of vulnerabilities that was new to me, which I appreciated. I recommend this book if you are interested in the topic of zero-day vulnerabilities and the markets around them as it is comprehensive. Finally, I really appreciate that Perlroth included extensive notes at the end that offer a variety of formal and informal citations for further reading and justification for many comments made.

I offer this opinion once again because this blog will be a bit more negative, focusing on parts of the book that I took exception with. If I am correct about any of the following criticisms, it is just as much a reflection on her editors as it is on Perlroth, so this is not leveled at her specifically. I understand errors are made, we all make them; that said, the process of writing a book should have such content go through at least three sets of eyes (if not more) so I think it is fair to level this criticism to everyone involved. While I may use Perlroth’s name below, consider it to mean “Perlroth et al” in the context above.


Errata

p6: “After three years of covering nonstop Chinese espionage, a big part of me was reassured to see that our own hacking capabilities far exceeded the misspelled phishing emails Chinese hackers were using to break into American networks.” This line so early in the book made me groan and double-take as it seems to unfairly equate an incredible variety of Chinese threat actors into a single category. While I have no doubt this characterization is true for some, I think it is not true in the bigger picture. Further, it implies that the U.S. doesn’t misspell anything in phishing mails our hackers send out to foreign targets.

p7: “The [NSA] appeared to have acquired a vast library of invisible backdoors into almost every major app, social media platform, server, router, firewall, antivirus software, iPhone, Android phone, BlackBerry phone, laptop, desktop, and operating system.” Just a page after the prior quote, this started out with my skepticism. Perlroth seems to conflate zero-day exploit with backdoor, despite them being very different things. This may be a bit nitpicky, especially since the Wikipedia definition blurs the lines, but given the topic of the book is all about vulnerabilities and exploits I think it is important to point out. Coming up in InfoSec, a vulnerability could get you access to a resource and a backdoor could as well. The difference was that one was accidental and the other intentional, but both came from the vendor. Even if the NSA pressured a vendor to include a backdoor, which they have, it is still a vendor-shipped flaw in the code with intent to subvert the security of the system. Perhaps this is terminology that is all but lost like the classic hacker vs cracker vs … debate.

p7: “Zero-days are the most critical tool in a hacker’s arsenal. Discovering one is like discovering the secret password to the world’s data.” There’s a lot to unpack here. First, zero-days are not the most critical tool in a vast majority of hacker’s arsenals. As Perlroth covers, the use of phishing attacks that do not necessarily rely on a vulnerability, or uses known but unpatched ones, are quite effective. Second, the “secret password to the world’s data” is hyperbole since any one zero-day will get you access to a fraction of a single percent of the world’s data. This description makes it sound like just one, any one, has a level of access and power they simply do not.

8 “A series of seven zero-day exploits in Microsoft Windows and Siemens’ industrial software allowed American and Israeli spies to sabotage Iran’s nuclear program.” For a book on zero-day exploits to start out incorrectly stating how many zero-day exploits were used in Stuxnet is discouraging. More so that Perlroth later cites Kim Zetter’s definitive book on the topic with glowing praise, yet still gets this bit wrong. As previously reported and referenced on Wikipedia, Stuxnet used four zero-day exploits. [1] [2] [3]

p8: “Depending where the vulnerability is discovered, a zero-day exploit can grant the ability to invisibly spy on iPhone users the world over, dismantle the safety controls at a chemical plant, or send a spacecraft hurtling to earth [sic]. In one of the more glaring examples, a programming mistake, a single missing hyphen, sent the Mariner 1 – the first American spacecraft to attempt an exploration of Venus – off-course, forcing NASA to destroy its $150 million spacecraft 294 seconds after launch, or risk it crashing into a North Atlantic shipping lane or worse, a heavily populated city.” While there has been rumors and urban legends around hacking satellites, a vast majority of which have been debunked, using the Mariner 1 as an example of what can go wrong due to a vulnerability without caveat is unfair. That spacecraft had a bug in it that has not been said to be exploitable. This is essentially the same as the countless “vulnerability reports” of applications that do nothing more than demonstrating a stability issue leading to a crash, not something that can realistically be exploited by a bad actor. This example is frustrating because later in the book, Perlroth provides many examples that are just as compelling and actually happened as a result of vulnerabilities.

p63: “In the hacking community, Charlie’s paper was alternately celebrated and condemned. Some cast him as an unethical researcher who, by selling his zero-day to the government and waiting so long to come forward with it, had put millions of Linux users at risk. Some pushed to have his cybersecurity license stripped.” I can’t imagine what this is supposed to mean since there is no such thing as a “cybersecurity license.” Even if this was to mean some certification, that is very different than a license.

p123: “Once the worm was on that first Natanz computer, a second Microsoft Windows zero-exploit kicked in – though technically, this second exploit wasn’t a zero-day at all.” This isn’t ideal for explaining this topic to non-technical readers. Introducing a new term, presumably by mistake, then immediately contradicting it in the same sentence is confusing.

p222: “Jobert would send discs flying out of Michiel’s hard drive from two hundred yards away.” I debated if this belonged in the hyperbole blog or this one and settled for here. There is simply no analogy to be had and even as an exaggeration this makes no sense.

p257: “Ekoparty was still dwarfed by Def Con, Black Hat, and RSA, but what it lacked in numbers and glitz, it made up for in raw creative talent. Absent were the booth babes and snake-oil salesmen that had overrun the big hacking conferences in the States.” Perhaps a bit nitpicky here, but of the three conferences listed, only one is a “hacking conference”. That conference does not have booth babes and essentially only merchandise vendors, so no more snake-oil salesmen than any other conference, including Ekoparty I would wager. Further, note that Black Hat has been held on three continents for many years now.

p263: “When I got to my room, the door was ajar .. Everything was just how I had left it, except the safe that had held my laptop. It was wide open. My computer was still inside, but in a different position .. I wondered if this was some kind of warning shot. I took a sober look at the laptop. It was a loaner. I’d left my real computer at home and stuck to pen and paper at the conference. There’d been nothing on the laptop when I’d left; I wondered what was on it now. I wrapped it in an empty garbage bag, took the elevator back down to the lobby, and threw it in the trash.” Personally, I find this brief part of Perlroth’s visit attend Ekoparty in Buenos Aires mind-boggling. She describes the conference as having the “best exploits on the market”, representatives from large companies looking to recruit, and countless attendees looking to sell exploits, all in a chapter titled “Cyber Gauchos“. With all of that, and the topic of the book she was researching, why would you ever throw away that laptop? Keep it, take it to someone capable of determining if it was backdoored and how. If lucky, figure out where it was accessed from in the subsequent weeks to perhaps get an idea who was behind it. That would have been a fascinating story by itself and a great addition to this chapter. Instead? A laptop with what might have been high-end unique malware was just thrown in the trash.

p332: “The only trace that it had been used was a second, complementary NSA exploit, code-named DoublePulsar, that was often used to implant EternalBlue into machines.” I think this is backwards as DoublePulsar is the implant (backdoor) and EternalBlue the remote vulnerability (CVE-2017-0144) that can be exploited to implant it.


It’s Complicated

There is one more piece of Errata that is complicated to unpack. This is due to just two lines containing quite a few bits of information, but the associated citations in the Notes section being missing or problematic. From page 6 -7 in Chapter 1, pardon the image as WordPress.com doesn’t apparently let you highlight sentences, only blocks:

The notes for chapter 1 provide citations for some of the content including in this order: a Mariner 1 incident, Menn’s article on “the NSA’s interception of Yahoo data”, Fehri’s article on the Times delaying a NSA wire-tapping story, Snowden / Vargas-Cooper bit about the same delay, and a Perlroth story leak covered by Smith. Compare the cited references to the book paragraph quoted above and it breaks down as:

  • First line is not cited but covered by many easy-to-find articles including this one by Reuters in 2013.
  • Second line is problematic as Perlroth writes that the CIA infiltrated factory floors at “leading encryption chip makers” to backdoor them, but does not offer a citation. Given that it follows a voluntary backdoor in RSA, it is a separate series of events. The wording also does not match the well-known Crytpo AG saga. Given the severity of such incidents, it seems like this would come with a reference.
  • Third line is cited as coming from Joe Menn’s article “Exclusive: Yahoo Secretly Scanned Customer Emails for U.S. Intelligence“. The first issue is that the cited article about Yahoo & Google only mentions Google twice, both to say the company denied doing any searches. The second, and more serious issue, is that the article title itself specifically counters the narrative that Perlroth offers. Yahoo scanning customer emails on behalf of the U.S. Intelligence agencies is very different than them “hacking their way into the internal servers before the data was encrypted”.
  • Fourth line is cited in the notes.

If four lines in a book are that problematic, especially in chapter one, it can be difficult to digest the rest of the material. It may cause the reader to constantly question if what they are reading is accurate and well-founded.


Parting Gift

The following quote is in the book, but one where Perlroth quoted someone she spoke with. I offer this up as a parting gift because of just how absurd it is. I wish I could say it is out of context, and it might be, but any lost context seems not to have made it in the book if so.

That’s why the Europeans are so good at writing exploits, after babies, European parents get like a year to hack.” — Charlie Miller

My Photography is Popular

According to Ken Rockwell, via the first result of a Google search, the definition of a professional photographer is someone:

.. who earns 100% of his income from photography. This is the definition required for entrance into the secret Nikon and Canon factory support organizations. People who earn less than 50% of their income from photography are amateurs.

I am not a professional by that standard, but I had to look because I was curious if viewership mattered. That came after Google notified me that another one of my photos had been viewed over one million times via the exciting subject line of “A lot of people are seeing your photo on Google Maps!

I’m sure there are some amazing photographers that sell their works in stores that have been seen by tens of thousands of people, and yet my quick shot of a local Qdoba has somehow been viewed by that many? That’s about 25% of the population of the greater Denver metro area.

I’ve long thought that these mails and such numbers are wrong, but no way to prove it. There certainly isn’t one million actual humans that interested in the local Qdoba. That means there is likely a lot of automated scraping of images or applications that load it for other purposes. I’m sure there is a blog out there explaining this but I think I would rather enjoy the notion that my photography is just that awesome.

[Update: As I suspected, something else going on. Gillis explains why the numbers are high: “Comes down to the manager of the Google maps business listing. Each “view” of a business counts as a image view if you’re one of the top 6 images for the business. Whereas if you’re ‘below the fold’ views only come if folks scroll down to your pic“. He goes on to sayOh yeah, you’re the main image for the business. So everytime someone tries to navigate there manually, you get a view.” So basically, that manager owes me free queso and chips.

Perlroth, Terminology, and Hyperbole

I finished reading “This Is How They Tell Me The World Ends” by Nicole Perlroth a few weeks ago but haven’t had time to write this blog, and likely another, based on specific aspects of the book. I have written two blogs on topics covered in the book after reading it already, but both written before completing the book.


Overall the book was an enjoyable read. It is clear that Perlroth covers the topic of zero-day exploits and the exploit market very well, based on a lot of research and interviews with key players. The book exposed some things that were new to me so I enjoyed some chapters very much. The book also gave me a sizable list of items to do further research on including several ideas for FOIA requests. Finally, I think the epilogue was especially well done and would serve as a great ~ 20 page primer on the topic and where the world is going in the realm of exploits and hacking campaigns. If you are interested in the topic I do recommend this book.


That said, this blog is about one issue I have with the content. Starting in the prologue and continuing throughout several chapters of the book, Perlroth uses language that is arguably one step past hyperbole, seemingly crossing the definition of “intensifier” and falling squarely into “extreme exaggeration“. This has been a problem for over twenty-five years in Information Security with one of our worst being “Cyber Pearl Harbor“, which is also used in this book. While such terms are dramatic and hook a reader they are counter-productive as they unfairly explain or refer to concepts that are not as serious or damaging as the terms used.

Equating two unrelated terms to explain one concept to an audience not familiar with it is common enough, and we all do it. But consider the definition on an analogy which is “a comparison of two otherwise unlike things based on resemblance of a particular aspect“. The key, I believe, is “resemblance of a particular aspect” which can really be interpreted differently. If I compare a rocket to an automobile to make a comparison about travel because they both can move and transport people, does that count? Sure, but it sucks as an analogy and doesn’t make the point very well. When that gets taken to an extreme, you have a logical fallacy known as a false analogy.

To me, that is where analogies or descriptions like “a Cyber Pearl Harbor” fall. Until a computer intrusion can routinely sink ships, destroy aircraft, kill over 2,300, and wound over 1,100 people in just over an hour, I don’t think that is an appropriate term to use. If such an event happens once, perhaps calling it “the Cyber Pearl Harbor” would be acceptable. Further, what part of the attack on Pearl Harbor resembles a computer attack? Until that can be answered, journalists and security professionals should endeavor to use more grounded analogies that can explain a concept without embellishing or incorrectly comparing something in the virtual computer domain to a kinetic real-world item or event. While Perlroth’s first use of this term was quoting “security experts”, she had the opportunity to temper that with a caveat or explanation, but did not.

Even calling exploits a “weapon” begins to push that boundary as most people think of a kinetic weapon like a knife or gun that has wounded or killed millions in the last 100 years. With that, here is a sampling of some of the analogies and terminology Perlroth used throughout her book to illustrate the problem. What is perhaps most unfortunate about this is that the book is well-written and did not need to do this to make it interesting. To me, it was actually a detraction and did not add to the topic.

  • xvi: Russian hackers made a blood sport of hacking anyone…
  • xvi: For five long years, they shelled Ukrainians with thousands of cyberattacks a day…
  • xviii: The very same Russian hackers that had been laying trapdoors and virtual explosives
  • xxi: .. is what happened when the NSA’s most powerful cyberweapons got into our adversary’s hands. So in March 2019 I went to Ukraine to survey the ruins for myself.
  • xxvi: If Snowden leaked the PowerPoint bullet points, the Shadow Brokers handed our enemies the actual bullets: the code
  • p8: In the process, “zero-day exploits” became the blood diamonds of the security trade.
  • P257: They were here to recruit, perhaps, or broker the latest and greatest in Argentine spy code.
  • p294: Russian hackers had been shelling Ukraine’s computer networks with cyberattacks, and the timing was ominous.
  • p295: And like those attacks, the KillDisk had a ticking time bomb.
  • p324: But nation-states could just as easily bolt digital bombs and data wipers onto the tools, detonate data, and take America’s government agencies, corporations, and critical infrastructure offline.
  • p334: Across the world, people started ripping their computers out of the wall.
  • p348: Nobody had even bothered to tell the mayor that the virus hitting his city had been traveling on a digital missile built by the nation’s premier intelligence agency.
  • p349: One assailant locked up its systems with ransomware; another detonated EternalBlue to steal data.
  • p381: It was Nakasone who played a critical role in leading Nitro Zeus, the U.S. operation to plant land mines in Iran’s grid.
  • p383: They – the hackers, the officials, the Ukrainians, the voices in the wilderness – had always warned me that a cyber-enabled cataclysmic boom would take us down.

One thing to note is that on rare occasion, Perlroth did temper such wording. One example can be found on page 49 where she says “Again, these weren’t weapons. They were gaping security holes that could be exploited to break into hardware and software, and the American taxpayer was being asked to bankroll the entire supply chain.” Unfortunately, this comes after several lines in the bullet points above and many more like it.

Similarly to using exaggerated terms for exploits and digital attacks, Perlroth does the same when describing hackers. While describing a complex world of zero-day exploits, brokering them, and the impact they can cause, she falls back on tired clichés to describe the people using these exploits. Here are a few examples:

  • xix: .. simply beyond that of any four-hundred-pound hacker working from his bed.
  • p22: .. he did not resemble the emaciated hackers and former intelligence types glued to their computer screens
  • p23: .. a little colorful for men who wore black T-shirts and preferred to work in windowless dungeons.
  • p23: .. their diet subsisted of sandwiches and Red Bull.
  • p28: Vendors didn’t want to deal with basement dwellers
  • p28: … pimply thirteen-year-olds in their parents’ basements
  • p28: … ponytailed coders from the web’s underbelly
  • p30: Hackers who barely made it out of their basements would get hammered…

If I used hyperbolic clichés to describe Nicole Perlroth, a New York Times reporter, I wonder how many journalists I would offend?

April 2021 Reviews

[A summary of my movie and TV reviews from last month, posted to Attrition.org, mixed in with other reviews.]


Bad Trip (2021)
Medium: Movie (Netflix)
Rating: 4.5/5 fingercuffs what?!
Reviewer: jericho
Reference(s): IMDB Listing || Netflix
If pranks aren’t your thing, move on now. If pranks are your thing, then this is your new jam. Eric André brings his physical humor to bear in a series of pranks that are hilarious and sometimes disgusting. The premise is a simple road trip for two friends from FL to NY to pursue a “love interest”, with Tiffany Haddish playing the escaped felon protagonist chasing the guys for “stealing” her car. Several of the pranks are not only Rated R, but certainly not for young ones or those easily disgusted. If dark, sick humor born out of pranking people is appealing, this movie should keep you laughing.


Barbaren / Barbarians (2020)
Medium: TV (Netflix)
Rating: 4/5 nothing like potato cakes, jalapeno poppers, and a beefy sandwich for breakfast
Reviewer: jericho
Reference(s): IMDB Listing || Netflix || Trailer
This six episode series plays out the battle of the Teutoburg Forest between Germanic tribes and a Roman Empire legion occupying their territory. The big point of intrigue is that an officer in the legion was German-born and taken by the Romans as a child. His allegiance is in question fairly early, setting us to wonder which side he will help. The show starts out a bit slow to introduce the players, establish each side, and eventually build up to the historic battle. The Germanic tribes end up led by Thusnelda, wonderfully played by Jeanne Goursaud, under a tenuous supposition but proves her loyalty and dedication to the tribes shortly before battle. The story is simple, acting good, and the story climax is worth the wait.


A Knight’s Tale (2001)
Medium: Movie (Netflix)
Rating: 5/5 the tale gets better every time you watch it
Reviewer: jericho
Reference(s): IMDB Listing || Trailer
I started re-watching this movie again recently), and I was reminded how it is such a fun movie. I love how they ‘modernized’ it a bit with clever music integration. Queen’s “We Will Rock You” at one point in the lists while waiting for a knight and then again for David Bowie’s “Golden Years” during the banquet and dance scene. Since jousting might be a bit boring watching it over and over, the cinematography was well-done with lead-ins to the jousts and well-executed slow motion pauses. Overall this movie brings the laughs and definitely the feels, so make sure you have onions nearby to cast blame elsewhere.

The Rundown: CVE IDs & RESERVED Status

During the process of assigning a CVE ID, there is a time period between the assignment and the disclosure, and again between the disclosure and it becoming available on MITRE’s CVE site or NIST’s National Vulnerability Database (NVD). During this period, the ID will be shown as RESERVED.

First, it is important to note that when an ID is part of a CVE Numbering Authority (CNA) pool of IDs to potentially be assigned, it is shown in RESERVED status. If an ID is not assigned that year, it is then supposed to be moved to REJECT status the following year per CVE rules. Bit odd they say the reason for the rejection will “will most often be stated“; most often and not always? If a CNA other than MITRE assigns an ID and the researcher and/or vendor later publicly discloses the vulnerability, it may still show as RESERVED. This happens when the CNA fails to notify MITRE despite being stipulated in CNA rules. It can also happen if the CNA notifies MITRE but it slips through the cracks. Pretty simple right?

If MITRE assigns the ID to a researcher, it is a lot more likely to stay in RESERVED status after disclosure because the researcher who publicly discloses the vulnerability doesn’t always notify MITRE. You may ask why MITRE doesn’t open the CVE with details themselves if it is public, and that is a great question! The simple answer is, MITRE does not really monitor public sources for disclosures any longer. Back in the day they would monitor Bugtraq and NTBugtraq and encouraged researchers to just disclose directly to those mail lists. During that time, they also said they monitored four sources for new vulnerability information but notably did not include either mail list, instead including four different summaries being published. I think we can chalk that up to an error in documentation.

For those not familiar with MITRE’s coverage for CVE, consider that they no longer publish three lists of interest. As late as March 6, 2016, MITRE maintained lists of what they considered:

  • Full Coverage Sources” – “For nearly all issues disclosed by the source that could be associated with a CVE entry, there will be an associated CVE entry, regardless of the criticality of the issue. Although a source is named as Full Coverage, we purposely use the phrasing “nearly all issues disclosed” to allow the flexibility to potentially postpone coverage of minor issues.”
  • Partial Coverage Sources” – “The source will be actively monitored but issues will be processed and associated with CVE entries based on a variety of editorial judgments.”
  • Must-Have Products” – “All products listed are considered to be “must have.” This means that we will ensure that a CVE-ID is issued for any public disclosure for the product provided that the following to provisions are met…”

By the end of 2016, that page maintained the same URL but changed content to become what would be their CNA coverage page. By early 2017, the old URL redirected to a new one about requesting a CVE ID and CNA coverage, which is roughly the same as currently available. This is an important shift in how CVE operates as MITRE basically threw in the towel trying to actively monitor disclosures and moved to relying almost entirely on CNAs and researchers coming to them.

The part that is truly baffling to me is that this tax-payer funded project, costing us millions a year, thought that monitoring 48 sources for “full” coverage, 45 sources for “partial” coverages, and guaranteeing 45 products was ever adequate to begin with, and somehow a burden at that point. They also disclaimed that they “actively [monitor] many sources beyond this list. These sources include things like blogs from vulnerability researchers, conference proceedings, and media outlets.” Despite that claim and coverage, MITRE was already missing thousands of vulnerability disclosures a year including ones from sources on their list.

What should worry consumers of CVE is that other vulnerability databases monitor a lot more sources than that for a lot less money. Any claims of it being more complicated or the issue being due to their processes mean there is an incredible amount of red tape or horribly outdated technical processes that were never updated. If another database can monitor literally several thousand sources a week for a fraction of the price, it speaks to MITRE not evolving over the years. Whew, glad that wraps it up!

Sorry, one last thing. Like entries in REJECT status, we can’t trust entries in RESERVED status either. Based on above and how MITRE operates, we know there are bound to be quite a few vulnerabilities where a researcher requested an ID, published details, and did not notify MITRE. Their backwards choice of not monitoring sources for disclosures means a disclosure may sit in RESERVED status for some time. How long? I went poking around a bit for fun and found this one. At the time of this blog, CVE-2000-1253 is still in RESERVED status (archive).

The issue? That was disclosed in 2015, and likely earlier. The actual vulnerability details were public at far back as 2003, maybe earlier. The good news? If you aren’t worried about remote root on a medical device, no need to be worried about this one.

The Rundown: CVE IDs & REJECT Status

For analysts and practitioners that digest CVE regularly, you will likely be familiar with CVEs that are in REJECT status. If you are new to CVE or not familiar with some of the more gritty details, a CVE assignment may be rejected for various reasons. When that happens, it will receive a capitalized REJECT status:

The REJECT links to a page that offers more information, but as of April, 2021, actually links to the correct page but the wrong anchor. I’ll link to the correct anchor for your reference, which gives us several reason an ID might be rejected including “it being a duplicate CVE Record, it being withdrawn by the original requester, it being assigned incorrectly, or some other administrative reason.

At the time of this blog, there are almost 9,500 IDs that have been rejected. A significant portion of those come from MITRE being more proactive and enforcing that CVE Numbering Authorities (CNA) reject unused IDs from prior years, along with a general increase in the total CVE assigned per year.

The process of rejecting, and the presence of REJECT entries is straightforward.

That’s right, if I am taking the time to blog about a topic seemingly so easy, there’s probably more to it. In this case, I wanted to point out a couple examples of CVE IDs that are in REJECT status, but highlight issues. The first is a simple one that underscores that the process of CNAs rejecting CVE IDs may have a problem, or that MITRE has an issue in the way they described the rejected ID. We’ll take CVE-2018-1226 (archive), that was rejected because “The CNA or individual who requested this candidate did not associate it with any vulnerability during 2018. Notes: none.” That is easy enough, right? The problem is that it was rejected by March 19, 2018. Not even a quarter of the way through 2018 and it was rejected because it was not associated with a vulnerability that year? That seems problematic. I’m sure there is a good explanation for this, but the description sure doesn’t do it.

You may think that pointing that out is pedantic, and you are right. However, there is an important reason we need to be pedantic and expect accurate descriptions from CVE, even for a rejected entry. What if the REJECT message was factually incorrect? What if that CVE ID represented a valid vulnerability that impacted your organization? If you rely on CVE/NVD you would have a blinds pot as a result of errors in their process, which are critical to you. Looking at two older rejected CVE IDs as an example, CVE-2015-0788 (archive) and CVE-2015-0789 (archive), we see that both are in REJECT status because they were not associated with a vulnerability in 2015.

Looking closer, we can see that the assigning CNA was Micro Focus International. As such they should be the single source of truth and provenance for any vulnerability information associated with those CVEs. MITRE would be secondary and should not necessarily be trusted if there is a dispute. In this case, there is a dispute in the form of NetIQ Identity Manager release notes listing both CVEs as fixed issues in version 4.5 Service Pack 2.

NetIQ was founded in 1995, acquired by Attachmate in 2006, and then acquired by Micro Focus in 2014. With this document we see the conflict where Micro Focus says that they were assigned, represented legitimate vulnerabilities, and were fixed and CVE says they are rejected.

The takeaway here is that while a CVE may be listed as REJECTed, trust, but verify.

The Rundown: CVE IDs, Meanings, & Assumptions

For almost two decades, CVE has been considered an industry standard for vulnerability tracking. A CVE ID can be affiliated with many vulnerabilities, in a format like CVE-2014-54321. Note my choice in ID, from 2014 with a consecutive set of numbers. That is because I specifically chose a ‘sample’ CVE that was set aside as an example of the CVE ID Syntax Change in 2014. This change occurred when it was determined that 9,999 IDs for a single year was not going to be sufficient. Technical guidance on this is available, as well as more basic information and the announcement about the change. Starting out with this hopefully demonstrates that there may be more to an ID than meets the eye.

Fundamentally, the ID is simple; you have the CVE prefix, followed by a year identifier, and a numeric identifier. In the CVE used above, it would represent ID 54321 with a 2014 year identifier. Fairly simple! But you are reading an entire blog on these IDs by me so the spoiler is here. It isn’t so simple unfortunately. I want to give a rundown of what a CVE ID really is, and set the record straight. Why? Because I don’t think MITRE has done a good job with that, and worse, actively works against what could be a clear and simple policy. We’ll use CVE-YEAR-12345 as a representative example for the purpose of discussing these IDs to be clear about which part of an ID we’re talking about.


When CVE was started in 1999, assignments were made based on a public disclosure. However, from the beginning, the YEAR portion almost immediately was not guaranteed to represent the year of disclosure. This was because MITRE’s policy was to assign an ID for a pre-1999 vulnerability using a CVE-1999 ID. We can see this with CVE-1999-0145 which was assigned for the infamous Sendmail WIZ command, allowing remote root access. This feature was publicly disclosed as a vulnerability on November 26, 1983 as best I have determined (the Sendmail changelog). While it was a known vulnerability and used before that, it was privately shared. If there is a public reference to this vulnerability before that date, leave a comment please!

The takeaway is that a vulnerability from 1983 has a CVE-1999 identifier. So from the very first year, MITRE set a clear precedent that the YEAR portion of an ID does not represent the year of discovery or disclosure. You may think this only happened for vulnerabilities prior to 1999, but that isn’t the case. In the big picture, meaning the 22 years of CVE running, an ID typically does represent the disclosure year. However, per one of CVE’s founders, “because of CVE reservation, sometimes it aligned with year of discovery“. That is entirely logical and expected as a CVE ID could be used to track a vulnerability internally at a company before it was disclosed. For example, BigVendor could use the CVE ID not only for their internal teams, such as communicating between security and engineering, but when discussing a vulnerability with the researcher. If a researcher reported several vulnerabilities, using an ID to refer to one of them was much easier than the file/function/vector.

For the early CVE Numbering Authorities (CNA), companies that were authorized to assign a CVE without going through MITRE, this was a common side effect of assigning. If a researcher discovered a vulnerability on December 25 and immediately reported it to the vendor, it may be given e.g. a CVE-2020 ID. When the vendor fixed the vulnerability and the disclosure was coordinated, that might happen in 2021. The founder of CVE I spoke to told me there “weren’t any hard and fast rules for CNAs” even at the start. So one CNA might assign upon learning of the vulnerability while another might assign on public disclosure.

Not convinced for some reason? Let’s check the CVE FAQ about “year portion of a CVE ID”!

What is the significance and meaning of the YEAR portion of a CVE ID
CVE IDs have the format CVE-YYYY-NNNNN. The YYYY portion is the year that the CVE ID was assigned OR the year the vulnerability was made public (if before the CVE ID was assigned).

The year portion is not used to indicate when the vulnerability was discovered, but only when it was made public or assigned.

Examples:

A vulnerability is discovered in 2016, and a CVE ID is requested for that vulnerability in 2016. The CVE ID would be of the form “CVE-2016-NNNN”.
A vulnerability is discovered in 2015 and made public in 2016. If the CVE ID is requested in 2016, the CVE ID would be of the form “CVE-2016-NNNNN”.

All clear, no doubts, case closed!

That clear policy is conflicting or may introduce confusion in places. Looking at MITRE’s page on CVE Identifiers, we see that the “The process of creating a CVE Record begins with the discovery of a potential cybersecurity vulnerability.” My emphasis on ‘discovery’ as that means the ID would reflect when it was discovered, and not necessarily even when it was reported to the vendor. There are many cases where a researcher finds a vulnerability but may wait days, weeks, months, or even years before reporting it to the vendor for different reasons. So it is more applicable that the ID will be assigned based on when the vendor learns of the vulnerability in cases of coordinated disclosure with a CNA. Otherwise, a bulk of CVEs are assigned based on the disclosure year.

It gets messier. At the beginning of each year, each CNA will get a pool of CVE IDs assigned. The size of the pool varies by CNA and is roughly based on the prior year of assignments. A CNA that disclosed 10 vulnerabilities in the prior year is likely to get 10 – 15 IDs the subsequent year. Per section 5.1.4 of the CNA rules, any IDs that are not used in a calendar year should be REJECTed if they were not assigned to an issue. “Those CVE IDs that were unused would be rejected.” But then, it stipulates that the CNA can get “CVE IDs for previous calendar years can always be requested if
necessary.
” So per current rules, a CNA can request a new ID from a prior year despite REJECTing IDs that were previously included in their pool. That means it is entirely optional, up to each CNA, on how they assign.

[Update: Note that the pool of IDs a CNA gets one year may not be the same the next. Not only in regards to the size of the pool, but the first ID may be in an entirely different range. e.g. 2019-1000 vs 2020-8000.]

The take-away from all this is that we now have many reasons why a CVE ID YEAR component does not necessarily tie to when it was disclosed. The more important take-away? If you are generating statistics based on the YEAR component, you are doing it wrong. Any statistics you generate are immediately inaccurate and cannot be trusted. So please don’t do it!


Finally, a brief overview of the numeric string used after the YEAR. Going back to our example, CVE-YEAR-12345, it is easy to start to make assumptions about 12345. The most prevalent assumption, and completely incorrect, is that IDs are issued in a sequential order. This is not true! Covered above, CNAs are given pools of IDs at the beginning of each year. Oracle and IBM assign over 700 vulnerabilities a year, so the pool of IDs they receive is substantial. There are over 160 participating CNAs currently, and if each only received 100 IDs, that is over 16,000 IDs that are assigned before January 1st.

In 2021, the effect of this can be seen very clearly. Halfway through April and we’re already seeing public IDs in the 30k range. For example, CVE-2021-30030 is open and represents a vulnerability first disclosed on March 28th. According to VulnDB, there are only 7,074 total vulnerabilities disclosed this year so far. That means we can clearly see that CVE IDs are not assigned in order.

Saving Bugtraq

In July of 2019, many noticed that the Bugtraq mail list stopped having posts approved, including Art Manion at CERT. Since there are many other outlets for vulnerability disclosure, such as the Full-Disclosure mail list, Packetstorm, Exploit Database, and increasingly on GitHub, it didn’t receive much attention. It wasn’t like the days when the list was created when there were very few places to disclose that would be seen by other security professionals and hackers. Despite that, the list has a long history and many came up in their respective scene recognizing what it represented.

The last post to the list, as of now, is dated July 26, 2019. In December of 2019 I tweeted to SecurityFocus and Symantec, its parent company at the time, asking if they had killed the list. I received no reply. Months passed and I got curious again, so I reached out to both companies via email trying to ascertain the status of the list. Two of the three public addresses I found on their website immediately bounced as undeliverable while the third went unanswered. I shared that update with Twitter as well in May.

After the last Tweet, someone reached out and offered to help me figure out the disposition of Bugtraq. We started chatting in May and they went to work. You may think this would be a relatively simple task and it would be for smaller companies. However, remember that while Symantec acquired SecurityFocus back in 2002, Broadcom acquired Symantec in November, 2019, and then Accenture acquired Symantec from Broadcom in April, 2020. You can imagine the amount of chaos going on in that organization and the layers of management along with the vast number of departments.

During that initial chat, I said “a lot of people don’t want to see the Bugtraq list just vanish given its history. We’re hoping Broadcom starts it back up or will pass it off to someone else in the industry to run.” That same day my contact figured out the general org structure involved and where to start asking around. A couple weeks later they reported back that it fell under an Accenture business unit, that there was discussion going as to the disposition, and that the pandemic was slowing things down. Jump to August, 2020, and they reported back that they were still working on it and that “breathing life into [the list] might be possible”.

In August, before they checked in with that update, I had decided to update the Wikipedia entry for the Bugtraq list as it was pretty sparse originally. I added a significant amount to better document the history around the list as well as some highlights like some controversies. My contact said those updates were actually helpful in gaining traction which I thought was cool. Nay-sayers about Wikipedia take notes! A few months passed and my contact reached back out in November with an update saying “I have a bit of an uphill battle here”. Giving it back to the community was being discussed, but we both immediately realized the next challenge if that happened; who would run it. No chance in hell I would. I said that if they posted to the list asking, I am sure they would get many volunteers. Vetting those and figuring out a viable long-term option might be tricky though.

In January, they messaged again saying “I have a few battle scars and ultimately lost the fight for [it]”. That was almost at the same time that I read the January 15 shutdown message that was posted to the list. I was one of several that Tweeted about it, lamenting about the loss.

I sent another message to my contact thanking them for fighting for it, and that I was happy a clear message had been sent finishing off the list. There was some concern about the possible fallout for the team, and that they “still remember hiring folks who said their goal was to be referenced on the Bugtraq list.” That was a great reminder that today claiming CVEs is some misguided notion of skill while back then, getting a post to Bugtraq approved meant a lot.

We continued the conversation on January 16 and they cryptically told me “there may be hope yet”, citing a ZDnet article that apparently got the attention of some executives. I joked with them saying “that would be an epic unintentional troll, if it got resurrected weeks later” to which they agreed. The list admins allowed one response to the post through that day, a shout-out from the old-school hackers of UPT. A day after that, the list admin sent a mail titled “On Second Thought…” stating that based on feedback, they have “decided to keep the Bugtraq list running. We’ll be working in the coming weeks to ensure that it can remain a valuable asset to the community for years to come.” Accenture followed that up with a more lengthy blog about the list revival.

Here we are months later and I thought back to part of our conversation in which I told them I “wish people knew just how long you had to fight on this and how much of a hurdle it was just to post the list.” They said it was probably a story best told over a beer, or something harder, suggesting I probably don’t know the half of what they went through to get all of this rolling. So I wrote this blog with the hope that they said it was ok to post, to share the story. InfoSec is full of heroes that work behind the scenes, fighting the good fight, and trying to make things a bit better. They deserve more recognition than they get. This is just one example of that. So thank you, so much, for your work in helping keep the historic list alive.

March 2021 Reviews

[A summary of my movie and TV reviews from last month, posted to Attrition.org, mixed in with other reviews.]


Coming 2 America (2021)
Medium: Movie (Amazon)
Rating: 4/5 Zamunda Ministry of Propaganda approves
Reviewer: jericho
Reference(s): IMDB Listing || Amazon
Thirty years later, a sequel that was never supposed to happen according to Arsenio Hall. I’m glad they changed their mind! While a sequel that largely follows the same plot of the first, the movie does a good job of giving equal time to the new characters while giving a very healthy dose of cameos and an incredible amount of the original cast who returned. Wesley Snipes plays the goofiest, over-the-top, African warlord and he delivers. Jermaine Fowler and KiKi Layne are the breakout stars, and Leslie Jones who I usually don’t care for at all did a great job with her character. Very light-hearted and the movie doesn’t take itself seriously one bit, the way it should be.


Cosmic Sin (2021)
Medium: Movie
Rating: 0/5 This movie is the sin
Reviewer: jericho
Reference(s): IMDB Listing
Yes, the first ‘0’ review. This movie is every bad cliché you’ve seen in a war or sci-fi movie, combined with the worst dialogue, a healthy dose of continuity failure, and just total shit for the rest. Year is 2524, quantum travel, colonizing planets, aliens? Sure, I can suspend disbelief to enjoy that. Every single bit after that? Nope. It’s hard to describe just how bad it is, how every scene is a “what?” or “that makes no sense!” Add to that the most ridiculous armor, gliding through space wearing mostly normal clothes, and silly aliens. There were two big scenes that seemed like material was left on the cutting room floor, leaving me to wonder what even happened. One question asked in the movie several times is “was the encounter positive or negative for both sides?” Negative for me, thanks for asking


I Care A Lot (2020)
Medium: Movie (Netflix)
Rating: 4.5/5 a classic evil vs evil battle
Reviewer: jericho
Reference(s): IMDB Listing || Netflix
This is a crime movie, from start to finish. I had a notion of what the movie was about going into it, but it had a nice escalation moving past what I thought it was. There are no good people in this movie, not a single one; and that makes it fun and interesting. Pike is the standout star for sure, and Dinklage does a pretty good job playing a character that doesn’t immediately remind you of Tyrion Lannister (a challenge to be sure). One thing I really enjoyed was trying to guess who would come out on top, how it would end, and if it would be satisfying. I guessed wrong and it was quite enjoyable. The only complaint is the movie name; it just doesn’t fit to me.


Point Blank (2019)
Medium: Movie (Netflix)
Rating: 2/5 What’s the point? [This space intentionally left blank]
Reviewer: jericho
Reference(s): IMDB Listing || Netflix
An ER nurse and a career criminal are forced into an unlikely partnership in taking down a ring of corrupt cops threatening the lives of both their families. The film is a remake of the 2010 French film of the same name, originally called “Àbout portant“. I suspect this is a shitty remake of the original because it is a long series of boring clichés for the most part. The only refreshing thing is that Anthony Mackey, who is muscular, gets his ass handed to him because he is a doctor and not a fighter. I’d skip this one.


Cherry (2021)
Medium: Movie (Apple)
Rating: 5/5 definitely not cheery
Reviewer: jericho
Reference(s): IMDB Listing || Trailer
Despite primarily covering a small part of the lives of two characters, wonderfully played by Ciara Bravo and Tom Holland, the movie has an epic feel to it. That is helped by the movie having no lulls; scenes are only as long as they need to be before advancing to the next event. We’re given the story of an unnamed character coming of age through love, war, drugs, and crime. Throughout, the one constant in his life is his love for Emily even when the relationship is perhaps the worst thing for either of them. The acting, narration, and cinematography is outstanding and this movie is worth the watch.


3022 (2019)
Medium: Movie (Multiple)
Rating: 0.5/5 space junk, figuratively speaking
Reviewer: jericho
Reference(s): IMDB Listing || Amazon
This movie is supposed to be set in the year 2190, but every single part of the technology suggests it was set in 2005. I like when Sci-Fi leans away from making everything bright and full of beeps, but this runs in the opposite direction full tilt. That means the show, with a small cast set in a small space station, needs to carry the movie. And it simply did not do that. It feels like each person was filmed giving their lines without any co-stars around for tense scenes. Very little sense of chemistry and a lot of dialogue seemed unnatural. Avoid this trash.


The Ballad of Lefty Brown (2017)
Medium: Movie (Multiple)
Rating: 2/5 It’s a sad song
Reviewer: jericho
Reference(s): IMDB Listing || Amazon
I appreciate a good western, and I know a good one may be a little slow compared to other genres. This definitely fits the bill and revolves around a simple plot at first; Lefty vows to find the killer of his best friend. The cast is stellar, full of big names, yet none of the performances really stand out. Pullman plays Lefty well but the character just wasn’t compelling to me. Flanagan’s acting is over-the-top and he plays a boring stereotype. Caviezel’s stoic tough guy is boring and seemingly his normal go-to role. After the simple plot aspect concludes, the movie falls short on the rest of it giving the impression the writers felt they needed filler to round it out.


Unknown (2011)
Medium: Movie (Multiple)
Rating: 3.5 / 5 needs more ‘thrill’ in the ‘thriller’ designation
Reviewer: jericho
Reference(s): IMDB Listing || Trailer
This is a tough movie to review without spoilers, so maybe an anti-spoiler? You know something is coming at the end, to resolve the entire premise and plot of the movie. It does a poor job giving hints to let you guess which direction it will go, so you are on a scenic ride with no ability to look out the side windows. The one time they do give you a hint, you only realize it in hindsight because they don’t actually give you a hint. It comes across as “wait… that is poor writing” when there is a reason for it. Liam Neeson is very Liam in this movie where he plays Liam who gets a bump on the head and wakes up with some memory loss, only to find someone pretending to be him, and he has to figure it out.


SAS: Red Notice (2021)
Medium: Movie (multiple)
Rating: 1 / 5 Throw a red card on this one
Reviewer: jericho
Reference(s): IMDB Listing || Amazon
Ruby Rose stars in this movie with guns and badasses and shooting and fights and stuff. If that doesn’t sound exciting, neither was the movie. Rose plays for the evil side this time, not the proverbial “good guy”. The lead guy on the good side was so boring I mistook him for an extra until a few scenes in. As you might guess, the movie is full of plot holes and has quite the predictable ending. No one stands out in this movie as far as acting and there are several recognizable faces, none from notable shows either. Skip it unless you need to get sleep.