Factor of Ultimate Doom

Vulnerability disclosure presents a complex challenge to the information security community. A reductionist explanation of disclosure arguments need only present two claims. One end of the spectrum goes, “Only the vendor need know so no one else knows the problem exists, which means no one can exploit it.” The information-wants-to-be-free diametric opposition simply states, “Tell everyone as soon as the vulnerability is discovered”.

The Factor of Ultimate Doom (FUD) is a step towards reconciling this spectrum into a laser-focused compromise of agreement. It establishes a metric for evaluating the absolute danger inherent to a vulnerability, thus providing the discoverer with guidance on how to reveal the vulnerability.

The Factor is calculated by simple addition across three axes: Resources Expected, Protocol Affected, and Overall Impact. Vulnerabilities that do not meet any of the Factor’s criteria may be classified under the Statistically Irrelevant Concern metric, which will be explored at a later date.

Resources Expected
(3) Exploit doesn’t require shellcode; merely a JavaScript alert() call
(2) Exploit shellcode requires fewer than 12 bytes. In other words, it must be more efficient than the export PS1=# hack (to which many operating systems, including OS X, remain vulnerable)
(1) Exploit shellcode requires a GROSS sled. (A GROSS sled uses opcode 144 on Intel x86 processors, whereas the more well-known NOP sled uses opcode 0x90.)

Protocol Affected
(3) The Common Porn Interchange Protocol (TCP/IP)
(2) Multiple online rhetorical opinion networks
(1) Social networks

Overall Impact
(3) Control every computer on the planet
(2) Destroy every computer on the planet
(1) Destroy another planet (obviously, the Earth’s internet would not be affected -- making this a minor concern)

The resulting value is measured against an Audience Rating to determine how the vulnerability should be disclosed. This provides a methodology for verifying that a vulnerability was responsibly disclosed.

Audience Rating (by Factor of Ultimate Doom*)
(> 6) Can only be revealed at a security conference
(< 6) Cannot be revealed at a security conference
(< 0) Doesn’t have to be revealed; it’s just that dangerous

(*Due to undisclosed software patent litigation, values equal to 6 are ignored.)

Evaluating a web application scanner: Link coverage

Many web sites consist of thousands, tens of thousands, or even a few hundred thousand links. The initial approach to a scanning a 300,000 link site might be to give the scanner a starting URI, launch a scan, then sit back while the scanner attempts to navigate the entire site. This approach isn't wrong, but it is inefficient and often unnecessary.

There's good motivation for scanning every link of a web site: coverage. Coverage refers to the amount of the web application exercised by the scanner. It's an important factor to security testing because, in simple terms, a link that isn't crawled is a link that isn't tested. However, the real goal isn't coverage of links, but coverage of functionality. The site's functionality is responsible for accepting user input and reacting to it in some manner. This is where vulnerabilities occur.

Scanning 300,000+ links isn't feasible from either a scanner perspective or a time perspective. Many of the links could be redundant. For example, there could be 10,000 links that point to a database record like /document.cgi?id=1 through /document.cgi?id=10000. In such a case there's no need to go through all 10,000 to test the page's functionality with regard to XSS and SQL injection; it's just necessary to test the id parameter.

There are counter-arguments to the id example. Many site design patterns use parameters to control different code paths. For example, /page.cgi?action=viewProfile and /page.cgi?action=editUser involve (as the parameters imply) two different sets of functionality. Consequently, the scanner shouldn't blindly throw away redundant links just because the page and parameter names are identical.

Ideally, a scanner should cover the target's site's full functionality. In practice, measuring coverage solely from a black box perspective is hard. Solutions can take the brute force approach, scan every link, or an iterative approach that slowly narrows the scanner's focus. Some possible methodologies are

- Divide the web site into logical areas based on directory structure. Scan those areas separately.

- Sort the list of crawled URIs. Look for redundant links. Create scan rules (e.g. black lists) that avoid those links.

- Determine high-risk areas of the web site. Create scan rules (e.g. white lists) that instruct the scanner to only visit those links.

yawnjacking

So, I was asked to comment about clickjacking today. Technically, it isn't a new vulnerability (IE6 fixed a variant in 2004, Firefox fixed a variant in September 2008), but a refinement of previous exploits and ennobled with a catchier name. It gained widespread coverage in October 2008 prior to the OWASP NYC conference when Jeremiah Grossman and Robert Hansen first said they would describe the vulnerability, then cancelled their talk for fear of unleashing Yet Another Exploit of Ultimate Doom.* The updated technique combines devious DOM manipulation with well-established attack patterns to make a respectable type of attack.

I still hope that this doesn't make it into the OWASP Top 1o. (I'll explain why elsewhere.)

Anyway, in the interest of further polluting the internet with opinionated cruft, here's more information about clickjacking:

Clickjacking tricks a user into clicking on an attacker-supplied page while the user only sees the appearance and effect of clicking on a plain link. The attacker identifies an area in the target HTML that should receive the click event. This HTML is placed within an IFRAME such that the X and Y offsets of the frame place the target area in the upper left-hand corner of the frame’s visible area. This target IFRAME is visually hidden from the user (though the element remains part of the DOM). Then, the IFRAME is set within a second page (the content of which doesn’t matter) beneath the mouse cursor and, very importantly, dynamically moves to always be underneath the mouse. Then, when the user clicks somewhere within the second page the click is actually sent to the target area even though it appears to the user that the mouse is only above some innocuous link.

Essentially, an attacker chooses some web page that, if the victim clicked some point (link, button, etc.) on that page, would produce some benefit to the attacker (e.g. generate click-fraud revenue, change a security setting, etc.). Next, the attacker takes the target page and places a second, innocuous page over it. The trick is to get the victim to make a mouse click on what appeared to be the innocuous page, but was actually an invisible element of the target page that has been automatically, but invisbly, placed beneath the cursor.

The attack relies on luring a user to a server under the attacker’s control or a site that has been compromised by the attacker. Web site owners who ensure their site is free of cross-site scripting or other vulnerabilities can prevent their sites from being used as a relay point for the attacker. Yet other successful attacks, such as phishing, also rely on luring users to a server under the attacker’s control. The relative success of phishing implies that just securing web applications at the server isn’t the only solution because users can be tricked into visiting malicious web sites.

The core of the attack occurs in the browser, which is where the real fix needs to appear. The problem is that browsers are intended to handle HTML from many sources and provide mechanisms to manipulate the location and visibility of elements within a web page. Consequently, any solution would have to block this attack while not inhibiting legitimate uses of this functionality.

*Yes, I made you scroll all the way down here to get the link. How evil is that?

Baud boy, baud boy, what'cha gonna' do?

Matthew Broderick was l33t* years before Trinity ran Nmap and pulled off an OpenSSH sploit. Seriously, it's not that hard to run a port scanner and download a canned exploit. David Lightman (Broderick's character) put real effort into his gear. Plus, the Matrix sequels were philosophical silliness dolled up with CGI to arouse drowsy neurons. WarGames explored some similar themes with better plot and better acting as summed up in David Lightman's "Is it a game... or is it real?" vs. Neo's "Whoa."

The movie's hacking premise rests on the tools in chapter 18 of AHT3. Wardialers also featured in the non-fiction account of computer espionage, The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage, by Cliff Stoll.

More recent examples of what can be done with a laptop, modem, and free time can be found in this SCADA presentation. (The author is from New Zealand. If you look closely at some of the photos you can see hobbits.) The presentation also debunks a few myths about the Ultimate Doom (UD) that could be caused by messing with SCADA systems. While UD isn't impossible, the most common examples of potential UD cited in news stories are significantly overblown.

*This is the only time leetspeek will appear on this web site. I promise.

Insecurity is like writing good and what you end sentences with

Pick a programming language. There are good odds that a web application has been written in that language and better odds that the application contains at least one vulnerability. Many vulnerabilities result from simple coding mistakes that look obvious once they're identified, just as incorrect adverbs and sentence-terminating prepositions stand out to anyone who pays attention to English grammar. Secure coding has many parallels with good writing (or writing well). Grammar rules make communication clearer.

Straying from the path of grammar isn't always bad: text messaging, quick e-mails, inside jokes serve specific purposes. Incorrect grammar can even be unintentionally funny. Incorrect coding might lead to funny error messages or logic loops, but it also leads to security vulnerabilities.

In the last two years at my current job I've written roughly 30,000 lines of C++ code. Every once in a while the QA team finds a bug or reports a core discovered in the released code. During my periodic code review and re-factoring I come across even more undiscovered bugs that haven't yet manifested themselves.

Well-written code should be more secure code. (This assertion, like many others made here have anecdotal support, but no empirical support -- beware that common sense can often turn into nonsense if subjected to the scrutiny of testing and validation.) Yet code that can be parsed and compiled correctly doesn't inherently imply secure code. Just as documents can have non sequiturs and lack coherent flow so too can well-written code fall into logic traps or misaligning a variable's time of check with its time of use.

Metaphors for computer security -- cars, onions, castles, moats, cheese (I made up that last one) -- are usually stupid, unhelpful, and break down under the slightest inquisition of relevance. Writing an essay, e-mail, etc. at least shares the same physical process and more closely resembles the good and bad aspects of adhering to a language's rules and the ease with which simple mistakes can be made.