Migrating posts

Check out the new site in support of my new book! New content will be posted on that site and old posts from here will eventually be migrated.

Briefly

Cloud computing means CSOs can deal with the security of information rather than infrastructure.

Briefly

XSS vulnerabilities are the cockroaches of the Internet.

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.