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:


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:


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:


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.


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.


CVE-ID:  CVE-2008-3623

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


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:


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).

Perlroth and the History of Microsoft Vulns

While reading “This Is How They Tell Me The World Ends“, early in the book I ran across a single line that made me double-take. I took a note to revisit it after a complete read since it was so early in the book. For those familiar with my blogs, I tend to write about vulnerability statistics and this one fits the bill. This blog is a bit different in that a single line provoked it, but re-reading the section for clarity still takes me down other rabbit holes. Ultimately, this is a good example of how one sentence can have a lot of interpretations depending on how you read it, what statistics you use, and the deeper context that the sentence is embedded in.

Below are some additional lines that offer the full context of the line in question:

The first shift in the wind was Bill Gates’s memo. In 2002, after a series of escalating attacks on Microsoft’s software and customers, Gates declared that security would become Microsoft’s top priority. (P35)

On January 15, 2002, just as iDefense was getting going, Gates fired off the cybersecurity equivalent of the “shot heard round the world.” From that point on, Gates said, security would be the company’s “highest priority”. (P37)

What the security community wrote off as a stunt became an economic force. Microsoft froze new products and dredged up existing ones, ripping its software apart and training nearly ten thousand developers to build it back up again with security principles at the core. For the first time, procedures were put in place to embrace the hacking community. Microsoft set up a customer service line for hackers, tracked each caller and even logged their psychological quirks, noting which hackers needed to be handled with kid gloves, which had rock-star status, and which were just trolls. It instituted a regular system for rolling out software patches, releasing them on the second Tuesday of every month – “Patch Tuesday” – and offered customers free security tools.

And while plenty of zero-day bugs were still discovered, the frequency and severity of Microsoft bugs started to dry up. (P38)

For those not familiar with the memo, titled “Trustworthy computing”, it can be read in full here. The question that came to mind was, did the frequency and/or severity of Microsoft bugs go down? Before we answer, remember that this is fairly broad since it encompasses all Microsoft bugs, not specific to Windows or Internet Explorer for example. It is also important to note that Perlroth says they started to dry up, but not for how long. On the back of the Gates memo it would be expected that some researchers may change their attitude toward disclosure if they could sell the exploits for a higher payout. Finally, all of what follows is kind of moot because Perlroth’s statement is made on the back of a known unknown. That is, we know there are zero-day bugs discovered, but by nature, they are only zero-days if not publicly known.

Perlroth says two more lines that essentially tips her hand, I believe, demonstrating that her comments were made in mindsight based on extrapolation, not fact. First, she qualifies that she joined the security beat eight years after this memo. Second, she says:

The ripple effect of Gates’s [sic] memo could be seen far from Redmond, in underground dark web forums and in hotel rooms at the big security conferences.

The dark web barely existed in 2002. Given that Tor was released in September of that year, the first hint of dark web sites would have been starting. Gates’ memo was published eight months before Tor was released in fact. It’s hard to imagine that there were already established well-known forums to trade or sell vulnerabilities that would have a noticeable change at that point. With all of that in mind, I think that the rest of this rabbit hole is academic at best but illustrates why we must be careful when describing vulnerabilities in such a manner.

The Stats

All Microsoft Vulns, 2001 – 2005, per VulnDB

There was a significant drop in volume from 2002 to 2003 so it is easy to make this assessment in a very limited picture. But by 2004 it was back up quite a bit. Given what I outlined above about her tenure in the security beat along with questionable statements around the dark web as well as making statements based on unknown factors, the question here is how did she arrive at this conclusion. Further, the severity did not drop from 2002 to 2004 either.

The stats above are from VulnDB with the advantage of hindsight and a comprehensive collection of disclosures from that period. If someone made such a conclusion based on disclosures, it likely would have been based on CVE. Looking at only disclosures with a CVE ID, it does not change for the disclosure trends or severity.

Microsoft Vulns w/ CVE ID, 2001 – 2005, per VulnDB
Microsoft Windows Vulns, 2001 – 2005, per VulnDB
Microsoft Internet Explorer (MSIE), 2001 – 2005, per VulnDB

We see a dip in disclosures from 2002 to 2003 for both Windows and MSIE, but both rebound to varying degrees in 2004. Then Windows shoots up higher in 2005 while MSIE drops in 2005, which could just have been the browser war with Firefox and Opera heating up. That leads us to one more section from page 38:

Finally, did the bugs dry up or did their perceived value go higher, so people were less likely to disclose or sell for lower prices? For a book that dives deep into the value of 0days I figured this would be the hot take. Oh wait, it is, right after saying the frequency/severity dried up, Perlroth says:

Then, in the shadows, a growing number of defense contractors, intelligence analysts, and cybercriminals started doling out higher rewards to hackers who promised to keep their bug discoveries secret. In these subterranean circles, people started assigning a far higher value to Microsoft zero-day exploits than what iDefense was paying. 

So the fun part is go back to the charts and speculate. If the premise is that the Gates memo caused bugs to dry up because they were perceived more valuable, as outlined shortly after by Perlroth, why did the disclosures rebound in 2004? Did Microsoft suddenly stop caring about security a year later? Was 2003 just an abnormal, albeit coincidental, year for disclosures? Were there other factors at play?

There are a lot of questions that Perlroth nor the vulnerability statistics answer.

RSA Hack Thoughts

I read the article “The Full Story of the Stunning RSA Hack Can Finally Be Told” by Andy Greenberg in Wired and several things stood out to me. So this is my commentary on the article and events that are covered.

“It opened my eyes to supply chain attacks.” says Mikko Hypponen, chief research officer at F-Secure, who worked with Hirvonen on the company’s analysis of the RSA breach.

While the RSA hack was certainly novel in one way, going after the cryptographic seeds to the two-factor authentication fobs, the bigger concept was certainly not new. Even in the late 80’s and early 90’s, the same concept played out many times. While vulnerabilities were prevalent and breaking into most machines was fairly easy, there were high-value targets that proved challenging. To achieve that, some hackers would target the vendors of the operating systems and break in there first. The primary targets were the bug databases where customers reported issues as well as the source code of the operating system. These two things could give them a huge advantage in compromising additional systems. Seeing this same strategy play out twenty years later should not have been that new to anyone that had been around during that timeframe.

“After 10 years of rampant state-sponsored hacking and supply chain hijacks, the RSA breach can now be seen as the harbinger of our current era of digital insecurity – and a lesson about how a determined adversary can undermine the things we trust most.”

After two decades of every type of organization in just about every country getting hacked, defaced, and data stolen, how exactly is this a ‘harbinger’? Governments, military, and security companies all popped for decades, but this one is a harbinger to what exactly? More organizations getting hacked?

A staffer in Australia had received an email with the subject line “2011 Recruitment plan” and an Excel spreadsheet attached to it. He’d opened it. Inside the file was a script that exploited a zero-day vulnerability – a secret, unpatched security flaw – in Adobe Flash, planting a common piece of malicious software called Poison Ivy on the victim’s machine.

This paragraph sums up the “Advanced Persistent Threat” (APT) that hacked RSA. Other than using a zero-day vulnerability in Flash, one of five that year, nothing really stood out about this from the attacker’s side.

A hacker wouldn’t have even been able to exploit the Flash vulnerability if the victim had been running a more recent version of Windows or Microsoft Office, or if he’d had limited access to install programs on his PC – as most security administrators for corporate and government networks recommend, Hirvonen says.

Correct. Microsoft acknowledged shortly after details were published that if RSA has been running a newer version of Microsoft Office, it would have come with protections that likely would have seriously limited the attack and/or added additional hurdles for them to then pivot into the network. At every point of this story it is important to remember that this is a security company. They received huge money to give advice like “patch often” and “upgrade to the latest version” while not doing it themselves.

In fact, several RSA executives came to believe that at least two groups of hackers were in their network simultaneously – one highly skilled group exploiting the other’s access, perhaps, with or without their knowledge.

I wonder if anyone suggested the piggyback could have been the TAO group at the NSA? We know that is a modus operandi of theirs while watching nation-state adversary hackers.

On that Australian employee’s PC, someone had used a tool that pulled credentials out of the machine’s memory and then reused those usernames and passwords to log into other machines on the network. They’d then scraped those computers’ memories for more usernames and passwords—finding some that belonged to more privileged administrators. The hackers eventually got to a server containing hundreds of users’ credentials. Today that credential-stealing hopscotching technique is common. But in 2011 the analysts were surprised to see how the hackers fanned out across the network.

Which analysts were surprised? This was standard operating procedure for hackers in the late 80’s and early 90’s. This is exactly what the hacking group I was in did. The only difference is back then you were likely to find trusted relationships and common passwords between vastly different networks (e.g. an .edu machine and a .gov or .mil).

RSA executives told me that the part of their network responsible for manufacturing the SecurID hardware tokens was protected by an “air gap”—a total disconnection of computers from any machine that touches the internet. But in fact, Leetham says, one server on RSA’s internet-connected network was linked, through a firewall that allowed no other connections, to the seed warehouse on the manufacturing side.

To be clear, RSA executives did not understand what “air-gapped” means, or were lying about it. I feel this is an important take-away.

Breaches as extensive as the one carried out against RSA are often discovered months after the fact, when the intruders are long gone or lying dormant. But Duane says that the 2011 incident was different: Within days, the investigators had essentially caught up to the intruders and were watching them in action.

“I basically shut off RSA’s business,” he says. “I crippled the company in order to stop any potential further release of data.”

One person in legal suggested they didn’t actually need to tell their customers, Sam Curry remembers.

The RSA staffers began putting in nearly 20-hour workdays, driven by the chilling knowledge that the breach they were tracking was still unfolding.

This seems like a lot of fluffing RSA over this hack, but ultimately this was the same company that didn’t patch their Windows boxes and didn’t air-gap the seeds like execs claimed. Among all of these positive mentions for $person doing the right thing, we always get “that one guy we will not name” for proposing absolutely shitty ideas or having a bad take. I understand they won’t throw anyone under the bus but this is an important dichotomy.

“Recently, our security systems identified an extremely sophisticated cyberattack in progress,” (RSA notification)

Which part was sophisticated? Exploiting unpatched machines, pivoting, or stealing data? When seemingly every attack is a “highly sophisticated cyber attack“, is it really highly sophisticated?

In fact, by the time Castignola had landed in Massachusetts, both the NSA and the FBI had been called to help the company’s investigation, as had defense contractor Northrop Grumman and incident response firm Mandiant. (By chance, employees of Mandiant had already been on-site prior to the breach, installing security sensor equipment on RSA’s network.)

How’d that Mandiant software work out for RSA I wonder? It doesn’t seemed to have helped prevent or detect the intrusion at any point based on the story told.

Multiple executives insisted that they did find hidden listening devices—though some were so old that their batteries were dead. It was never clear if those bugs had any relation to the breach.

Uh, this isn’t burying the lede, but it is burying a big one. I have so many questions and I don’t recall there being answers to this specific bit. How were there so many listening devices in RSA executive offices? Had they never done a single bug sweep? Were each of the devices found investigated? Did they do a sweep of all offices after finding them? If not, why not?

“Well it didn’t take long for whoever cracked RSA to find a lock to fit that key,” Cringely wrote. “What if every RSA token has been compromised, everywhere?” Two days later, Reuters revealed the name of the hacked military contractor: Lockheed Martin, a company that represented a cornucopia of ultra-secret plans for weapons and intelligence technologies. In the days that followed, defense contractors Northrop Grumman and L-3 were also named in news reports.

Today, with 10 years of hindsight, Coviello and other former RSA executives tell a story that starkly contradicts accounts from the time : Most of the former RSA staff who spoke to me claim that it was never proven that SecurID had any role in the Lockheed breach. Coviello, Curry, Castignola, and Duane all argued that it was never confirmed that the intruders inside RSA’s systems had successfully stolen the full list of seed values in an uncorrupted, unencrypted form, nor the customer list mapped to those seeds necessary to exploit them. “I don’t think that Lockheed’s attack was related to us at all,” Coviello states flatly.

vs A Lockheed source with knowledge of the company’s incident response reaffirmed to WIRED the company’s original claims. “We stand by our forensic investigation findings,” the source says. vs In a briefing to the Senate Armed Services Committee a year after the RSA breach, NSA’s director, General Keith Alexander, said that the RSA hack “led to at least one US defense contractor being victimized by actors wielding counterfeit credentials,” and that the Department of Defense had been forced to replace every RSA token it used.

Can we figure out who is trying to re-write history here? Sure seems like RSA is despite several other organizations saying otherwise. That would explain why so many were willing to go on the record for this article.

Squirrel Tech Support

Last year in October, I did a release of Fox squirrels for Greenwood Wildlife Rehabilitation after they had been rehabilitated. These squirrels couldn’t go back exactly where they came from because the owner of the property wasn’t available to give permission, which is required by Colorado Parks and Wildlife regulations. A wonderful lady that was on the release candidate list offered to take them so I drove them to their new home. Since it was an October release and winter was close, each of the two batches got their own nest box to start out. Before I put them up, I noticed that there were a lot of other nest boxes already up. Come to find out she had been offering to take squirrels for many years.

I warned her about the danger of overcrowding, when the squirrel density is too high it can cause serious issues and lead to death for some squirrels. As they compete for food sources and are forced to spread out, they can move to yards or areas that are not as suitable for them. Forcing a squirrel out of their home has a high probability of leading them to their death, as they find themselves in a new area without food, shelter, or knowing escape routes. I ended up putting the boxes up because that late in the season we had no other viable release sites. Since she was supplementing their food with sunflower seeds, bird seed, and corn, it was a lot better option than anything else.

Jump to today when I get a call from her asking if I could help. Apparently one of her old nest boxes, that she thinks may be 20 years old, fell out of the tree this morning. She said no one from Greenwood or anywhere else she called could come help her put the box up. So I found myself driving out to Arvada to see if I could get it done quickly before hauling ass down south for an early afternoon appointment. I spent an hour, most of it trying to figure out a way to get it back up in the tree and stable. This was tricky because the support board for the nest box had rotted out, leading to it falling, and it wasn’t usable. I had to run to the local hardware store for a hammer and some eye hooks but ultimately it just wasn’t happening.

 Rotted original nest box.
Rotted original nest box.

I left but told her to call me later that afternoon while I tried to think of a solution. Shortly after I left, I got a call from her saying that Greenwood could spare one of the big nest boxes, identical to the one that fell. She left immediately to get it which meant over an hour on the road. I had planned on returning tomorrow to work on it but the idea of squirrels not having their nest overnight didn’t sit well with me. Unprotected and sleeping in a tree is very risky; predators and even the wind are threats. After my appointment down south I drove back to Arvada with my own ladder and drill which I knew would be needed for the new box.

New box built by a Boy Scout troop and donated to Greenwood.
New box built by a Boy Scout troop and donated to Greenwood. (Box is upside down)

I don’t know much about relocating squirrels from one nest to another. Since they enjoyed a protective nest box, I wasn’t sure if that factored in if it was being replaced by a similar one. They obviously look different and no doubt smell different to the squirrels as well. So I removed some of the bedding from the old nest box and put it in the new.

Bedding in the old box included leaves, twigs, dirt, and almost unrecognizable piece of fleece that was put in originally.
Bedding in the old box included leaves, twigs, dirt, and almost unrecognizable piece of fleece that was put in originally.

My hope was that the bedding being moved over would help the squirrels understand this was the new home. The next challenge came in the form of where to put the box. Whoever had put the old one up had a much taller ladder than hers or mine, so there was no way to get it back up that high. The angle of the tree made it so most of the trunk space was not suitable due to it being uneven, the box being angled, or branches.

The new box with old bedding moved over along with two new pieces of fleece since we didn't know how many squirrels lived in it
The new box with old bedding moved over along with two new pieces of fleece since we didn’t know how many squirrels lived in it.

Ultimately, we ended up removing an old bird house that had never been used since installation and putting the new box in its place. It wasn’t quite as high as I would have liked, but higher than some other nest boxes that have been put up. One side offered easy access to the box off the tree trunk but the other might not have been perfect, but a squirrel could definitely go from trunk to that entrance too. I left her place at 7pm with a strong hope that the squirrels who watched us do all that understood what had happened. She told me she’d watch tonight to try to see if any went in and would watch in the morning like she always did to see if squirrels emerged. I left a huge handful of sunflower seeds on top of the box and even more below at the foot of the trunk to help them while they adjust.

Today was the first day in my new career as Squirrel Tech Support apparently.

The new nest box hanging in the tree.

[Update: This morning she texted to let me know that squirrels were eating the seeds and one went into the new nest box. She says “Looking good for them!!!”]

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.


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 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, 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.