John Thomas Draper: Setting the Record Straight re: Cap’n Crunch Whistle

The tl;dr cliffnotes: John Draper was not the first to discover that a Cap’n Crunch whistle could be used for phreaking.


It is almost a ‘fact’ that John Draper, also known as Captain Crunch, discovered that a toy whistle in a box of cereal could be used to make free phone calls. I say ‘almost’ a fact, because so many people believe it, and so many people have written about it as if it were fact. Even recently, a magazine known for intelligent geeky facts parroted this falsehood:

Not long after Engressia shared this information with the other phreakers, John Draper discovered that a toy boatswain’s whistle that was included in boxes of Cap’n Crunch cereal in the late 1960s could blow a perfect 2600Hz tone.

Even going back to 1983, a book titled “Fighting Computer Crime” by Donn B. Parker carried the myth:

A young man just entering the U.S. Air Force to serve as a radio technician was fascinated with telephony and took courses on the subject at college and discovered the whistle that catapulted him to crime, infamy, and misfortune.

Google around for tales of Draper and the whistle will find a variety of sites that say he discovered it. These include the Snopes message board, a telephone tribute site, high school papers, and other archival sites. And this isn’t limited to more obscure sites, this ‘fact’ is still repeated by mainstream media articles.

While some in the industry have had doubts or heard tale that Draper did not discover the whistle’s significant tone, it wasn’t until last year that we finally got a definitive answer and story. Phil Lapsley wrote a book titled “Exploding the Phone” that gives an exhaustive history of phone phreaking and is a must read for anyone interested in the topic. Lapsley’s research put him in touch with many players of the time, and the real story emerged:

Page 155: Several years earlier a Los Angeles phone phreak named Sid Bernay had discovered you could generate a nice, clean 2,600 Hz tone simply by covering one of the holes in the plastic toy bosun whistle that was given away as a prize in boxes of Cap’n Crunch cereal. Armed with their Cap’n Crunch whistles Fettgather and Teresi and friends would cluster around pay phones at the airport and go nuts. [..] With Draper in the club the whistle trips expanded.

Page 166: (late summer of 1970) It was on one of those conference calls that John Draper discovered a new identity for himself. [..] One day Draper and Engressia were talking about using a Cap’n Crunch whistle to make their beloved 2,600 Hz tone, Engressia recalls, when Draper suddenly said, “You know, I think I’ll just call myself Captain Crunch. That’d be a good name.” Engressia immediately liked it. “It just fit him somehow,” he remembers. “It was just a good name for him. We called him ‘Captain’ a lot.” Captain Crunch was born.

Given that most of Draper’s modern reputation is based on his ‘discovery’ of the whistle, something he has done nothing to dispel or come clean about, I feel it is important to help set the record straight. While he may be an iconic figure in lore, even if undeserved, it is important to better understand what kind of person he was during this time.

Page 245: And as a rule universally agreed upon within their group, they avoided John Draper and his friends like the plague. “I tell you,” [David] Condon says, “Draper was the kiss of death. He was asking for it, he was looking for trouble.

Page 313: All this did not sit well with Steve Jobs and the other managers at Apple, who thought the Charley Board product was a bit too risky and, besides, they disliked Draper to begin with.

In addition to being disliked, Draper had a growing criminal record that included seven counts of violating 18 USC 1343 (Fraud by Wire, when he used a blue box to Australia, New York, and other places) in 1972, violating probation later in 1972, arrested in California in 1976, and indicted on three counts of 18 USC 1343 while on probation. To this day, Draper maintains it was a conspiracy:

Page 287: To this day, Draper maintains that he was framed. [..] “Well, it turns out that he had arranged with the FBI to tap that phone,” Draper says. “he told the FBI that I was going to be making a blue box call at that phone at that date and time.” The result was that the FBI now had a blue box call on tape with Draper’s voice on it. [..] You see, the informant that the Los Angeles office of the FBI sent up didn’t arrive in the Bay Area until Tuesday, February 24. The blue box telephone calls that Draper was eventually busted for occurred four days earlier, on Friday, February 20. And on that Friday the Los Angeles informant was still in Los Angeles, enjoying sunny southern California weather or breathing smog or whatever it is that LA phone phreak informants do when they’re off duty.

But this wasn’t the end of his crime. In New Jersey in 1977 he was arrested and charged with possession of a red box, which was later dropped. He was again arrested in 1977, this time in Pennsylvania, which led to him agreeing to a plea deal in 1978 to one count of possessing a device to steal telecom services. He was sentenced to 3 – 6 months in jail with credit for 1 month served. That charge and plea also meant he violated his federal probation for earlier crimes, sending him back to California to spend time in prison as well. During all of this time, two psychiatrists observed that Draper “tend[s] to pass himself off as the victim claiming that he has almost no control over all of the troubles that now beset him” and that he had “numerous paranoid delusions of being especially picked out for persecution because of his power and knowledge”. Both psychiatrists agreed that a jail would not be a good place for Draper, leading a judge to sentence him to a furlough program for one year. Finally, in 1987, he was caught forging tickets for the BART system which lead to a plea bargain, resulting in a misdemeanor.

I offer all of this up, courtesy of Exploding the Phone, as a reminder that many people in InfoSec consider him a hero of sorts, and feel that his history was beneficial to the world of phreaking. In reality, it was not. He was just another phreak at the time, did not discover the Cap’n Crunch whistle, was caught during his crimes several times, and then somehow became a telecom legend. To this day, Draper still tries to use his reputation to get handouts from the industry. If you want to support him, just be sure you understand who you are supporting, and why.

A Note on the Verizon DBIR 2015, “Incident Counting”, and VDBs

[This was originally published on the OSVDB blog.]

Recently, the Verizon 2015 Data Breach Investigations Report (DBIR) was released to much fanfare as usual, prompting a variety of media outlets to analyze the analysis. A few days after the release, I caught a Tweet linking to a blog from Rory McCune that challenged one aspect of the report. On page 16 of the report, Verizon lists the top 10 CVE ID exploited.

dbir-top10-cve

The bottom of the table says “Top 10 CVEs Exploited” which can be interpreted many ways. The paragraph above qualifies it as the “ten CVEs account for almost 97% of the exploits observed in 2014“. This is problematic because neither fully explains what that means. Is this the top 10 detected from sensors around the world? Meaning the exploits were launched and detected, with no indication if they were successful? Or does this mean these are the top ten exploits that were launched and resulted in a successful compromise of some form?

This gets more confusing when you read McCune’s blog that lists out what those ten CVE correspond to. I’ll get to the one that drew his attention, but will start with a different one. CVE-1999-0517 is an identifier for “an SNMP community name is the default (e.g. public), null, or missing.” This is very curious CVE identifier related to SNMP as it is specific to a default string. Any device that has a default community name, but does not allow remote manipulation is a rather trivial information disclosure vulnerability. This begins to speak to what the chart means, as “exploit” is being used in a broad fashion and does not track to the usage many in our industry associate with it. McCune goes on to point another on their list, CVE-2001-0540 which is an identifier for a “memory leak in Terminal servers in Windows NT and Windows 2000 allows remote attackers to cause a denial of service (memory exhaustion) via a large number of malformed Remote Desktop Protocol (RDP) requests to port 3389“. This is considerably more specific, giving us affected operating systems and the ultimate impact; a denial of service. This brings us back to why this section is in the report when part (or all) of it has nothing to do with actual breaches. After these two, McCune points out numerous other issues that directly challenge how this data was generated.

Since Verizon does not explain their methodology in generating these numbers, we’re left with our best guesses and a small attempt at an explanation via Twitter, that leads to as many questions as answers. You can read the full Twitter chat between @raesene, @vzdbir, and @mroytman (RiskIO Data Scientist who provided the data to generate this section of the report). The two pages of ‘methodology’ Verizon provides in the report (pages 59-60) are too high-level to be useful for the section mentioned above. Even after the conversation, the ‘top 10 exploited’ is still highly suspicious and does not seem accurate. The final bit from Roytman may make sense in RiskIO’s world, but doesn’t to others in the vulnerability world.

That brings me to the first vulnerability McCune pointed out, that started a four hour rabbit hole journey for me last night. From his blog:

The best example of this problem is CVE-2002-1931 which gets listed at number nine. This is a Cross-Site Scripting issue in version 2.1.1 and 1.1.3 of a product called PHP Arena and specifically the pafileDB area of that product. Now I struggled to find out too much about that product because the site that used to host it http://www.phparena.net is now a gambling site (I presume that the domain name lapsed and was picked up as it got decent traffic). Searching via google for information, most of the results seemed to be from vulnerability databases(!) and using a google dork of inurl:pafiledb shows a total of 156 results, which seems low for one of the most exploited issues on the Internet.

This prompted me to look at CVE-2002-1931 and the corresponding OSVDB entry. Then I looked at the ‘pafiledb.php’ cross-site scripting issues in general, and immediately noticed problems:

pafiledb-before

This is a good testament to how far vulnerability databases (VDBs) have come over the years, and how our data earlier on is not so hot sometimes. Regardless of vulnerability age, I want database completeness and accuracy so I set out to fix it. What I thought would be a simple 15 minute fix took much longer. After reading the original disclosures of a few early paFileDB XSS issues, it became clear that the one visible script being tested was actually more complex, and calling additional PHP files. It also became quite clear that several databases, ours included, had mixed up references and done a poor job abstracting. Next step, take extensive notes on every disclosure including dates, exploit strings, versions affected, solution if available, and more. The rough notes for some, but not all of the issues to give a feel for what this entails:

pafiledb-notes1

Going back to this script being ‘more complex’, and to try to answer some questions about the disclosure, the next trick was to find a copy of paFileDB 3.1 or before to see what it entailed. This is harder than it sounds, given the age of the software and the fact the vendor site has been gone for seven years or more. With the archive finally in hand, it became more clear what the various ‘action’ parameters really meant.

pafiledb31

Going through each disclosure and following links to links, it also became obvious that every VDB missed the inclusion of some disclosures, and/or did not properly abstract them. To be fair, many VDBs have modified their abstraction rules over the years, including us. So using today’s standards along with yesterday’s data, we get a very different picture of those same XSS vulnerabilities:

pafiledb-after1

With this in mind, reconsider the Verizon report that says CVE-2002-1931 is a top 10 exploited vulnerability in 2014. That CVE is very specific, based on a 2002-10-20 disclosure that starts out referring to a vulnerability that we don’t have details on. Either it was publicly disclosed and the VDBs missed it, it was mentioned on the vendor site somewhere (and doesn’t appear to be there now, even with the great help of archive.org), or it was mentioned in private or restricted channels, but known to some. We’re left with what that Oct, 2002 post said:

Some of you may be familiar with Pafiledb provided by PHP arena. Well they just released a new version that fixed a problem with their counting of files. Along with that they said they fixed a possible security bug involving using Javascript as a search string. I checked it on my old version and it is infact there, so I updated to the new version so the bugs can be fixed and I checked it and it no longer works.

We know it is “pafiledb.php” only because that is the base script that in turn calls others. In reality, based on the other digging, it is very likely making a call to includes/search.php which contains the vulnerability. Without performing a code-level analysis, we can only include a technical note with our submission and move on. Continuing the train of thought, what data collection methods are being performed that assign that CVE to an attack that does not appear to be publicly disclosed? The vulnerability scanners from around that time, many of which are still used today, do not specifically test for and exploit that issue. Rather, they look for the additional three XSS disclosed in the same post further down. All three “pafiledb.php” exploits that call a specific action that correspond to /includes/rate.php, /includes/download.php, and /includes/email.php. It is logical that intrusion detection systems and vulnerability scanners would be looking for those three issues (likely lumped into one ID), but not the vague “search string” issue.

McCune’s observation and singling this vulnerability out is spot on. While he questioned the data in a different way, my method gives additional evidence that the ‘top 10’ is built on faulty data at best. I hope that this blog is both educational from the VDB side of things, and further encourages Verizon to be more forthcoming with their methodology for this data. As it stands, it simply isn’t trustworthy.